分享技术见解、生活感悟和成长历程
最近做了一个简单的短链接服务，短链接使用自增 id 转化为 62 进制（10 个数字+26个小写字母+26个大写字母），但是发现插入数据库报了索引插入重复。 展示 创建测试表 CREATE TABLE `test` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `short_url` varchar(255) NOT NULL COMMENT '测试', PRIMARY KEY (`id`), UNIQUE KEY `short_url` (`short_url`) ) ENGINE=InnoDB AUTO_INCREMENT
show processlist show processlist 用来查看 MySQL 正在运行的线程，如果使用 root 账号可以看到所有用户的线程或者只能看到所使用账号自己的线程，当然如果该用户被赋予了 Process 权限也是可以查看所有用户的线程的。 命令使用展示： mysql> show processlist; +-----+------+-----------+------+---------+------+----------+------------------+ | Id | User | Host | db | Command | Time | S
今天要查询一个根据手机号返回用户的姓名，但是想要的 SQL 查询的结果的顺序和 in 后面数组里手机号顺序一样，使用 order by field(phone,111,222) select name,phone from users where phone in (18800000000,18800000000001) order by field(phone, 18800000000,18800000000001)
Kafka 简介 Kafka 是一个基于分布式的消息发布-订阅系统，它被设计成快速、可扩展的、持久的。与其他消息发布-订阅系统类似，Kafka 在主题当中保存消息的信息。生产者向主题写入数据，消费者从主题读取数据。由于 Kafka 的特性是支持分布式，同时也是基于分布式的，所以主题也是可以在多个节点上被分区和覆盖的。 信息是一个字节数组，程序员可以在这些字节数组中存储任何对象，支持的数据格式包括 String、JSON、Avro。Kafka 通过给每一个消息绑定一个键值的方式来保证生产者可以把所有的消息发送到指定位置。属于某一个消费者群组的消费者订阅了一个主题，通过该订阅消费者可以跨节点地接收
题目 合并两个有序链表，合并之后仍是有序的。 分析 这个题目很简单，类似于合并排序的合并过程。 实现 节点定义 type ListNode struct { Val int Next *ListNode } 单元测试 var mergeOrderListList = [][][]int{ { {1, 2, 3, 4}, {7,8,9}, {1, 2, 3, 4, 7, 8, 9}, },{ {1, 2, 3, 4}, {3,8}, {1, 2, 3, 3, 4, 8
题目 输入一个单链表链表的头结点，从尾到头打印每个节点的值。 题目很简单但是实现方法却可以有很多种，也能考察人的不同方面的知识。这里实现使用 go 语言。 实现 节点定义 首先说明这里不能使用各语言内置的链表，比如 java 的 LinkedList。这里要求的单链表只能有两个属性不能有其他的属性和方法。 go 语言定义如下 type ListNode struct { Val int Next *ListNode } 堆栈 or 数组 看到这个题目最先想到的就是用堆栈或数组来做，方法就是遍历所有节点放入到数组或堆栈然后再遍历打印。数组就比较简单了，这里写下堆栈的实现。 首先
什么是负载均衡 负载均衡就是用多台服务器对外提供单一服务，通常用于提高网站、应用、数据库或其他服务的性能和可用性，负载均衡是高可用网络架构的关键组件。 没有负载均衡的架构 有负载均衡的架构 为什么要负载均衡 配置再强的服务器都有服务上限，当单台的服务器无法支持所有用户请求的时候就扩充机器到到几台、几十台甚至更多来提供服务，这个时候需要我们合理的把用户请求分发到各个服务器，这就是负载均衡。 负载均衡要理解最重要的一点，我这里用了“合理的分发”而不是平均分发，因为负载均衡并不是简简单单的均分流量，我们需要考虑到不同的服务器硬件配置、网络情况来合理的分配分配流量以达到各个服务器均不超载、合理利用
什么是全链路压测 使用真实生产业务场景、在真实的生产系统环境下根据历史用户访问记录构造海量用户请求对整个业务链进行压力测试并生成报告，根据报告持续调优的过程。 为什么要全链路压测 我们针对单机器单系统的压测虽然可以掌握单个机器或服务的服务能力但是并不能依此来推测整个系统的服务能力，因为任何一个具体的业务系统都可能在系统容量、业务代码性能、物理机器、网络、中间件和各个系统之间调用或具体的业务流程中等等任何一点上存在瓶颈进而导致真个业务系统的服务能力下降，而这些众多的点我们没办法去确定具体那个点会成为瓶颈，我们只能通过全链路压测来测试服务能力找到瓶颈，因为我们要服务于用户而全链路压测的流量正是 m