新浪微博Redis优化实战：从30G到百亿级数据的蜕变

微博作为全球知名社交媒体平台，在其发展过程中，对数据库技术尤其是Redis的运用和优化经历了一个显著的历程。本文详细探讨了新浪微博在处理大规模数据和高并发场景下的Redis存储架构演进，以及遇到的问题和解决策略。 1. **业务场景与Redis应用**: - 新浪微博早期使用MySQL存储非结构化数据，如计数器(counter)和图(graph)数据，如通知提醒业务。随着数据量的爆炸式增长（Graph mc达到30G+，计数器mc达到10wTPS），MySQL的性能逐渐成为瓶颈，导致线程阻塞和访问速度下降。 2. **Redis存储架构**: - 初期阶段，为应对高TPS（每秒事务处理数）的需求，尝试通过扩大MC（Memory Cache）容量至40G，同时增加Graphdb的主从节点。然而，这并不能根本解决关系计算性能问题，因为Redis的O(1)查询特性使得它更适合这种场景。 3. **解决方案**: - 实施了将关系计算移至Redis的存储策略，利用Redis的高效数据结构支持复杂需求。同时，通过合理的数据分片和容量规划，避免了初期的扩容困难和内存超预期问题。 - 提高可用性方面，增加了所有Redis实例的Slave，并限制Master挂载Slave的数量，采用了M-S-S（主-从-从）模式，确保服务的稳定性。 4. **挑战与升级**: - 随着数据规模进一步扩大（Graphdb增至100G+），在低峰期发生了未预见的Redis崩溃事件。这促使团队进行批量升级、扩容和数据拆分，但也带来了其他业务的连锁反应，如负载不均衡和请求失败等问题。 5. **经验教训与总结**: - 技术选型中，开发速度与产品需求间的平衡至关重要。初期的技术不够成熟，数据分片不合理和业务混放导致了可用性问题。经过迭代优化，虽然仍有不足，但整体上已经实现了稳定的服务保障。 新浪微博的Redis优化历程揭示了在处理海量数据和高并发场景时，数据库技术的选择、容量规划、性能优化和可用性提升的重要性。随着技术的不断迭代，新浪在实践中不断学习和成长，为后续的数据库优化提供了宝贵的实战经验。