Redis分布式改造：高峰的实践与心得

"Redis的改造与实践是高峰作为nice服务端架构师在SDCC 2016上分享的主题，主要涉及Redis的分布式平台构建，包括全新的数据结构xset和解决Twemproxy的局限性。文章阐述了Redis改造的背景、设计思路、改造后的架构以及上线后的实际运行情况，同时也指出了改造后仍然存在的问题和挑战。" 在Redis的改造实践中，高峰首先介绍了项目背景。前期发展快速，导致上百台机器承载近千个实例，对集群管理和扩展性提出了更高要求。随着业务数据的快速增长，频繁的集群扩容成为必须。然而，官方和开源社区并未提供经过大规模验证的分布式解决方案，尤其是Twemproxy虽然性能优秀，但在集群管理方面存在局限，例如无法方便地进行水平扩展和运维管理。 针对这些问题，高峰提出了一种改造设计思路，构建了一个Redis分布式平台。该平台的核心是Metaserver，它负责维护整个集群的配置信息、拓扑结构、数据分布映射，并能执行数据迁移、主从切换等任务。在保持在线数据访问不经过Metaserver的前提下，redis-server和redis-proxy通过LVS（Linux Virtual Server）与Metaserver建立连接。 Redis改造的关键在于将数据固定分成2万个slot，每个分片持有部分slot，支持按slot粒度进行迁移。Redis实例会与Metaserver保持心跳，以便获取最新的集群状态。而Proxy作为中间层，不仅缓存slot与分片的映射关系，还负责处理读写分离、流量控制和白名单等功能。当集群信息发生变化时，Metaserver通过pub/sub模式实时通知Proxy。 在数据迁移过程中，Metaserver设定了时间限制，超时未完成则取消迁移。迁移期间，特定slot会被锁定仅允许读操作，迁移完成后，原实例才会清除旧slot的数据。尽管采取了这些措施，数据迁移仍可能引发数据重复，需要额外任务进行修正。 改造成果显著，上线半年后，系统支撑了100+应用，500+机器，2000+实例，每天处理400亿+流量。然而，改造后仍存在一些问题，如Metaserver的一致性不是强保证的，Redis实例的离线判断未采用多方仲裁，可能导致自动主从切换的风险，以及slot迁移的锁写操作仍有优化空间。 此外，文章还提到了一种名为xset的新数据结构，它是基于zset实现的，增加了限定长度信息。当xset达到预设长度时，新添加的数据会根据指定规则删除旧数据，实现了自动的容量控制。 这次Redis的改造与实践展示了如何应对大规模Redis集群的挑战，包括分布式管理、数据迁移和扩展性，同时也揭示了改造过程中遇到的问题及其解决方案，为类似场景提供了宝贵的经验。