Kafka是如何做到超高并发(百万级)的，设计很是精妙，配合巧用文件系统，mmap技术，消息批量处理，零拷贝，简洁的消费者逻辑来完成。尤其是他的暴力输入输出美学，深受启发，对某些应用场景很是有启发作用。

在使用 Python 操作文件时，很多人会使用with上下文管理器来操作。操作系统限制任何单个进程可以拥有的打开文件的数量，这个可以使用工具 ulimit 查看。我们每次操作文件都去使用with来管理上下文，with封装了 try…except…finally 编码范式，能在任何情况下(当然不包括断电)极大限度的帮你关闭文件。

本文记录了自己对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时，对象的内存被释放

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