"新浪微博在发展过程中面临了数据库性能瓶颈,主要体现在存储和计算能力上。在Redis前时代,他们依赖Memcached(mc)和MySQL,但随着数据量的增长,特别是关系计算需求增加,原有的架构逐渐无法满足需求。2010年,由于Graphmc的数据量增长到30G以上,MySQL的线程阻塞和访问卡顿问题突出,对List类型的业务处理不理想。为解决这些问题,初期尝试增大mc容量和优化关系计算,但效果有限。最终,新浪微博引入Redis作为存储解决方案,用于graph和counter,实现了关系计算的O(1)复杂度,并促进了更复杂的业务需求。
在Redis的存储初期,采用了Redis 2.0版本,Graph数据存储为hash,达到40G的容量和10w TPS,而Counter则有20G的容量和2w TPS。然而,随着时间推移,初期使用中暴露出了一些问题,如数据分片不足导致的扩容难题、部分数据类型使用不当造成内存超出预期,以及多个业务混放在同一Redis实例导致的拆分不便。此外,可用性也是一个挑战,小业务没有配置从节点,服务器故障可能导致数据丢失。
为了优化Redis的使用,新浪微博进行了以下实践和演进:
1. 数据分片策略优化:调整数据分片策略以支持更灵活的扩容,确保在数据量增长时能平滑扩展。
2. 数据类型选择:根据业务场景合理选择Redis的数据类型,避免因不当使用导致的内存浪费。
3. 业务隔离:将不同业务的数据分开存储,方便管理和维护,同时提高系统的稳定性和可扩展性。
4. 高可用性构建:为每个业务配置从节点,实现数据复制,提升服务的容错能力。
5. 监控与告警:建立完善的监控系统,对Redis的性能指标进行实时监控,及时发现并解决问题。
6. 持续优化:定期审查Redis的使用情况,寻找进一步的优化空间,如内存压缩、缓存策略调整等。
通过这些优化措施,新浪微博的Redis架构逐步完善,能够更好地支撑其业务需求,提供高性能、高可用的服务。随着技术的发展和业务的演变,他们可能还会探索更多的优化策略,如采用Redis Cluster进行分布式管理,利用Redis模dules扩展功能,以及利用AOF和RDB持久化策略保证数据安全等。"