加餐（七） | 从微博的Redis实践中，我们可以学到哪些经验？

在实际应用 Redis 时，你有哪些优化和二次开发的经验？ 分享一下我们对 Redis 的二次开发经验。 由于我们采用的 Redis 集群方案是 Codis，我们主要对 Codis 下的 Redis Server 进行了二次开发。 我们在做服务跨机房容灾和多活时，需要在两个机房各自部署 Codis/Redis 实例，并且两个机房的实例数据需要实时同步，以支持任意机房故障时，可随时切换应用流量到另一个机房继续提供服务。 但由于两个机房之间的网络是通过专线连通的，而专线的质量和稳定性是不如同机房内的，如果使用原生 的 Redis 主从复制方案，当专线长时间故障再恢复时，原生 Redis 主从复制会进行全量的数据同步。全量同步不仅对 master 节点有阻塞风险，同时也会对机房之间的专线的带宽产生巨大的压力，还会影响应用的机房流量切换。 所以我们对 Codis 下的 Redis 做了二次开发，对其增加了类似于 MySQL 的 binlog 模块，把实时的写命令通过异步线程写入到 binlog 文件中，然后开发了数据同步中间件去读取 Redis 的 binlog，向另一个机房实时同步数据，并且支持增量同步、断点续传，这样就可以兼容专线任意时间的故障，故障恢复后我们的同步中间件会从断点处继续增量同步 Redis 数据到另一个机房，避免了全量复制的风险。 同时，我们还对 Codis 进行了二次开发，在集成数据同步中间件时，兼容了 Codis 的日常运维和故障容错，例如集群内节点主从切换、故障转移、数据迁移等操作，保证了机房之间数据同步的最终一致性。 最后，我想说的是，对 Redis 进行改造，优点是可以更加适配自己的业务场景，但缺点是维护和升级成本较高，改造 Redis 相当于自己开辟了一个新的分支，公司内部需要投入人力去持续维护，需要平衡投入产出比。如果没有特别复杂的需求，一般使用官方版本即可，好处是可以第一时间使用最新版本的特性。

问题：微博采用的集群部署方案，不是Redis cluster？是自研的吗？

顺着专栏给的链接，先去看了《万亿级日访问量下，Redis在微博的9年优化历程 》，虽然没有机会面对类似微博这样的体量（2019年 100T+ 存储、1000+ 台物理机、10000+ Redis实例、万亿级读写、响应时间 20 毫秒），但是也算是大开眼界。 其实原文中的那个缓存、存储、队列技术选型流程图，就很有价值。 分享的很多内容不明觉厉，结合专栏的解析来看，可以感觉到微博团队在 Redis 运维方面做的比较深入。有一点疑问就是，基于 Redis 的早期版本做了很多二次开发，那么是否能够和 Redis 的新版本兼容？或者说是否反馈回了开源社区？ 老师最后总结的业务纵切、平台横切很有高屋建瓴的味道，当然，最终还是要靠代码实践。 有一点好奇，一般分享都是大厂如何在高性能、大容量和可扩展方面应用 Redis，有没有人分享过“小厂”是如何使用 Redis，直接拿开源版本上生产环境么？可能也够用。 希望以后有机会能回答课后题中关于 Redis 的优化和二次开发的问题。

请问老师，在冷热数据处理的图例中，异步读取冷数据，是直接从IO队列读取，这是异步处理线程发送读取命令后，然后从IO队列读取么？ 另外，如果需要读冷数据，是把冷数据再放回redis变成热数据么？

微博的 Redis 分享很棒，一直都觉得微博是个很厉害的平台。 另外老师总结得也很到位，更容易理解。

问题：冷热数据的迁移，是怎么操作的？由后台根据访问量自行迁移吗？

老师能展开说下longset是如何实现的吗？ 用数组的话，hash冲突后是怎么解决的

用户关注列表定制了longest这块，为什么不直接使用set结构？

对redis还没有二次开发过，感觉官方提供的能够完全使用都可以满足一般公司的业务需求

请问，“在 AOF 日志写入刷盘时，用额外的 BIO 线程负责实际的刷盘工作”这句话，额外的BIO线程是什么意思？