后端道亦有道

epoll全称 event poll，是 Linux 内核提供的一种基于事件回调机制的 I/O 多路复用技术，用于高效处理大量并发的网络连接。

服务稳定性保障是一个多维度、全方位的课题。想要构建高可用的服务体系，仅仅关注上下游视角是不够的。我们还需继续转换视角，从具体的业务场景着手，引入一项至关重要的策略——故障隔离。

对于数据库性能的优化，除了合理使用索引等SQL执行计划细节上的优化之外，在高并发场景，我们还需要在架构层面进行优化，提高数据库的读写性能。

常见的有固定窗口、滑动窗口、漏桶以及令牌桶这四种算法。当我们需要针对上游服务进行限流时，为了既能实现流量的平滑处理，又能允许一定程度的突发流量出现，我们往往会选用令牌桶算法。

当下游服务过载时，为了避免持续不断的请求导致下游迟迟不能恢复，甚至引发级联故障，我们需要熔断机制断开对下游的调用。

本文讲解超时和重试相关的知识，并用超时和重试解决了高并发场景下，面对下游偶现超时，我们服务可能存在的稳定性问题。

对于local cache，首先要解决程序启动时的效率问题。为了加速程序启动，我们可以采用本地文件加载和数据库轮询加载相结合的策略，之后是缓存更新问题，我们可以采用 RocketMQ 广播消费的方式。

本文讨论了大 Key 问题，并提出了两种有效的解决方案。首先是基于 PB 序列化的数据压缩方案，其次是基于版本号机制的大 Key 拆分方案。

今天我们就来聊聊，在大促抢购期间，有些商品访问 QPS 突然大幅度增高时，我们如何才能保障 Redis 访问的性能不受影响呢？

内存淘汰策略总共8种，大体上分为「不进行数据淘汰」和「进行数据淘汰」两类策略，针对「进行数据淘汰」这一类，又可细分为「在设置了过期时间的数据中进行淘汰」和「在所有数据范围内进行淘汰」这两类策略

Redis的过期删除策略原理介绍，使用命令和源码分析，本文展开详细介绍，并附带图例以便于读者更好的理解。

Redis大key问题除了会造成客户端以及服务端的性能问题，实际上也有可能影响到持久化的性能，这篇文章会详细分析

AOF和RDB都会用一个日志文件来记录信息，但记录的内容是不同的 - AOF记录的是操作命令 - RDB记录的是二进制数据

所谓快照，就是记录某一瞬间的内存数据，因此，不同于AOF日志记录的是操作命令，RDB文件的内容是二进制数据。因此在Redis恢复数据时，采用RDB的效率会更高，直接将RDB文件读入内存即可

Redis持久化技术中的AOF方法，每执行一条命令，就将该命令以追加的方式写入到AOF文件中，然后在重启时以逐一执行命令的方式进行数据恢复。

TiDB 目前获得了广泛的关注，我希望能写一些文章，自顶向上，由浅入深，讲述 TiDB 的一些技术原理，包括用户可见的技术以及大量隐藏在 SQL 界面后用户不可见的技术点。