新浪微博Redis优化实践与挑战

"新浪微博在发展过程中面临了数据库性能瓶颈，主要体现在Memcached（MC）的存储容量不足，MySQL处理高并发关系计算时的线程阻塞等问题。为了解决这些问题，新浪微博逐步引入了Redis作为存储架构，以提高系统性能和满足更复杂的业务需求。 在业务场景上，Redis在新浪微博主要应用于计数、关系存储以及通知提醒等功能。在数据规模方面，当时拥有6个IDC，超过500台服务器，3700多个Redis实例，存储着千亿条记录，占用超过24TB的内存，每天处理7千亿条命令，其中读操作达到1.2万亿次，写操作达到2千亿次。这显示了新浪微博的业务量之大和对数据库性能的极高要求。 在Redis引入之前，热数据主要存储在Memcached中，全量数据则落地到MySQL。但随着数据量的增长和新需求的出现，Memcached的容量限制和MySQL的性能瓶颈逐渐暴露。例如，2010年时，图数据（Graphmc）增长至30GB以上，峰值TPS达到10万，MySQL的线程阻塞导致访问延迟，列表类型业务的处理也不适应MySQL。 为解决这些问题，初期尝试了增大Memcached的容量和优化MySQL，但这些措施仅是临时缓解。最终，新浪微博选择了引入Redis作为存储解决方案，尤其是对于图数据和计数器。通过在Redis中存储数据，可以实现关系计算的O(1)时间复杂度，显著提高了处理效率。此外，Redis的引入也促进了更多复杂业务需求的实现，使得Graph数据库回归一主三从的架构。 在Redis的初期应用阶段，使用的是Redis 2.0版本。图数据以Hash形式存储，40GB数据在4台服务器上实现10万TPS，而计数器则在2台服务器上处理2万TPS的负载。然而，这个阶段也暴露了一些问题，如数据分片不足导致扩容难题，某些数据类型使用不当造成内存超出预期，以及多业务混合存储带来的拆分困难。此外，部分小业务由于没有配置从节点，服务器故障时可用性受到影响。 新浪微博的Redis优化历程展示了从传统的Memcached和MySQL架构向Redis过渡的过程，以及在这个过程中遇到的问题和解决方案。通过不断优化和调整，Redis成功地帮助新浪微博应对了高并发、大数据量的挑战，提升了系统的稳定性和性能，同时也推动了业务的快速发展。"