本文记录了自己对kafka消息模型的理解, 包括消息生产者和消费者是依据什么生产和拉取消息的, 以及kafka如何保障不同消费组不相互影响，如何保证同一个消费组内的消费者不重复消费消息, 比较适合刚入门的同学.

redis的主从同步会涉及到复制缓冲区, 复制积压缓冲区, 全量复制, 部分同步, replication buffer, 复制偏移量, 复制缓冲区限制, 高 I/O 操作, 磁盘快照 等知识点, 推荐几篇不错的文章

在部署redis时，为了保证稳定可用，很多情况下采用主从部署的方式，那么你就需要了解一些redis主从全同步和部分同步的知识和这个过程潜在的性能卡点，尤其是大数据量和高并发的情况下，复制缓冲区和复制积压缓冲区很容易出现写满问题。

Go的函数返回可以说是别出心裁，既可以用匿名返回值，也可以用命名返回值，虽然这两种方式都可以完成相同的功能，但是这里边还是有一些坑，尤其是在搭配defer的时候，返回的值可能不是你想的那样，很容易产生不太好排查的问题

与RDB持久化方式不同的是，AOF持久化是通过保存Redis服务器的写和选择db的命令实现。AOF持久化的方式，很容易让aof文件变得很大，同一个key，比如来来回回被设置删除，更改内容，因此需要对AOF重写，来压缩文件大小。

有两个命令可以执行RDB文件持久化，分别为save和bgsave，其中save会阻塞主进程进行持久化，这时候Redis服务器是不能接收和处理客户端发来的指令的，而bgsave则是派生一个子进程，进行同步，该命令不会阻塞主进程继续执行客户端传过来的指令，此时的不阻塞主进程。

我们都知道Redis是基于c语言开发的，c语言没有垃圾回收机制，所以Redis自己实现了一套垃圾回收机制，Redis的垃圾回收机制是通过计数来实现的。基本逻辑是：创建对象时计数被初始化后为1当对象被新的逻辑使用，其计数加1对象被逻辑用完，其计数减一当对象的计数为0时，对象的内存被释放

最近这两天几乎被某多多的员工猝死事件刷了屏，各种感慨和惋惜，正是美好年华，未来有着无限的可能，然而却止住了前进的脚步，静静的去了别的世界。这值得我们思考，最近几年类似的事情层出不断，为什么一直会有？我们到底该怎么选择？

索引列不能是表达式,提高索引的选择性,理解聚簇索引和非聚簇索引,使用explain验证我们书写的sql语句是否可以合理的利用索引，是否能提升查询效率，合理安排查询语句列顺序，避免使用多个范围条件。

首先明确的一点是MySQL的索引是在存储引擎层实现的没有特殊说明，谈论索引，多半说的是B-Tree，对于InnoDB来说每个叶子节点的逻辑页大小为16K。另外B-Tree对索引列是顺序组织存储，非常适合做范围查找。