📫作者简介：小明java问道之路，2022年度博客之星全国TOP3，专注于后端、中间件、计算机底层、架构设计演进与稳定性建设优化，文章内容兼具广度、深度、大厂技术方案，对待技术喜欢推理加验证，就职于知名金融公司后端高级工程师。
📫 热衷分享，喜欢原创~ 关注我会给你带来一些不一样的认知和成长。
🏆 2022博客之星TOP3 | CSDN博客专家 | 后端领域优质创作者 | CSDN内容合伙人
🏆 InfoQ(极客邦)签约作者、阿里云专家 | 签约博主、51CTO专家 | TOP红人、华为云享专家
🔥如果此文还不错的话，还请👍关注、点赞、收藏三连支持👍一下博主~
🍅 文末获取联系 🍅 👇🏻 精彩专栏推荐订阅收藏 👇🏻
专栏系列（点击解锁）
学习路线（点击解锁）
知识定位
全面讲解MySQL知识与企业级MySQL实战 🔥计算机底层原理🔥
本文目录
本文导读
本文基于微博业务规模，分析Redis在微博内部分布在各个应用场景的使用与优化，主要有微博数据库的技术选型，基于微博业务场景的Redis改进方案，Redis在微博的优化实践（Cache Service服务化、解决Redis容量过大问题、集群管理的实践）。
一、基于Redis的微博业务规模分析
Redis被广泛应用于微博的商业场景中，微博对Redis的基本改进可以分为两类：避免阻塞和节省内存。
业务需求是微博优化和改进Redis的出发点。微博中有很多业务，比如红包活动、粉丝数、用户数、读者数统计、信息流聚合、热榜等。同时，这些业务面临着非常大的用户数量，使用Redis的业务访问的数据量往往达到TB级别。作为一款直接面向终端用户的应用，微博用户的商业体验至关重要，这需要Redis的支持。
设计一个基于Redis的系统，可以提供高性能、高并发的读写访问，确保低读写延迟；能够支持大容量存储；灵活的展览保护对于不同业务的快速扩张至关重要。微博对Redis做了很多改进和优化。综上所述，它不仅改进了Redis本身的数据结构和工作机制，还基于Redis独立开发了新的功能组件，包括支持大容量存储的RedRock和实现面向服务服务的RedisService。
二、微博数据库的技术选型
微博数据库的技术选型，不仅仅包含Redis等NoSQL，还有队列、存储。
三、基于微博业务场景的Redis改进方案
在持久化方面，首先全量 RDB + 增量 AOF相结合的机制用于持久性需求，从而避免了数据可靠性或性能下降的问题。在Redis的官方4.0版本之后，还增加了RDB和AOF混合的机制。当AOF日志被写入和刷新时，使用额外的BIO线程来负责实际的刷新工作，这可以避免AOF日志刷新缓慢和阻塞主线程的问题。aofnumber配置项也已添加。此配置项可用于设置AOF文件的数量，控制AOF写入磁盘时的总文件大小，避免写入过多AOF日志文件导致的磁盘填充问题。
在主从数据库复制机制中，使用独立的复制线程来同步主从数据库，以避免阻塞主线程。
在节省内存方面，微博有一个典型的优化，那就是自定义数据结构。当使用Redis缓存用户的关注列表时，LongSet数据类型是为关注列表的存储而定制的。此数据类型是存储Long类型元素的集合，其底层数据结构是Hash数组。在设计LongSet类型之前，微博使用Hash集合类型来存储用户关注列表。然而，当保存大量数据时，Hash集合类型会消耗大量的内存空间。当缓存的注意力列表从Redis中删除时，缓存实例需要从后台数据库中读取用户注意力列表，然后使用HMSET将其写入Hash集。在并发请求压力较大的场景中，此进程可能会降低缓存性能，与Hash集相比，LongSet类型的底层使用Hash数组来存储数据，这不仅避免了Hash表的过度指针开销，节省了内存空间，还实现了快速访问。
可以看出，微博优化Redis的出发点与官方一再强调的Redis优化目标是一致的。
四、Redis在微博的优化实践
1、Cache Service服务化
微博海量的业务线对Redis的容量有不同的要求，随着业务的变化可能会有扩张和收缩的要求。为了灵活支持这些业务需求，微博对Redis进行了面向服务的转型（RedisService，即使用Redis集群来服务不同的业务场景需求，每个业务都有独立的资源，互不干扰）。这是一种多级缓存服务，可以解决高访问问题，高并发性和高可用性。基于该系统可以自动监控微博的流量，并支持自动伸缩，可以快速度过高峰并在高峰后回收机器，实现资源的充分利用。ConfigService意味着我们将配置放在配置中心，客户端从配置中心提取配置。有两种访问方法，第一种是SDK，第二种是多语言，通过代理将请求路由到后端缓存，DBA可以通过管理平台快速扩展和缩减资源。
如果想扩展Redis，我们可以使用Codis或Redis Cluster方法来实现这一点。多租户支持和业务隔离的要求是一致的，需要通过资源隔离来实现，这意味着分别部署来自不同租户或业务的数据，以避免资源混合。对于路由规则和监控功能，目前微博的方案是好的，即在 Redis proxy 代理中完成这两个功能。只有这些功能得到很好的实现，平台服务才能有效地支持不同业务线的需求。多级缓存中有四个角色：master、master-l1、slave和slave-l1。主设备master和从设备slave没有同步关系，但根据角色命名。master-l1有多组数据来承载热点，主设备是存储完整数据的基准数据。从设备通常用于多个机房的灾难恢复，slave-l1用于多个计算机机房的数据同步。这种同步会保证数据的最终一致性。
服务化的好处很多，所有Redis实例都形成了一个资源池，资源池本身可以很容易地扩展。如果新业务上线或旧业务下线，您可以从资源池中申请资源，也可以将未使用的资源返回资源池。Redis服务形成后，不同业务线使用Redis非常方便。您可以简单地允许业务应用客户端访问Redis服务集群，而不是由业务部门进行独立部署和运维。即使业务应用程序的数据量增加，也无需担心实例容量问题。服务集群本身可以自动在线扩展，以支持业务开发。
2、如何解决Redis容量过大？
为了解决容量过大的问题，可以将内存中的容量放入磁盘，例如微博区分热数据和冷数据（例如一些微博话题在首次出现时非常受欢迎，并且会有大量用户访问这些话题就要使用Redis服务。然而，在话题过去后，访问人数将急剧下降，这些数据将成为冷数据），将热数据保存在Redis中，并通过RocksDB将冷数据写入底层硬盘。此时，冷数据可以从Redis迁移到RocksDB并存储在硬盘上。这样就可以节省Redis实例的内存来保存热数据。同时，单个实例可以保存的数据量由整个硬盘的大小决定。
从图中可以看出，Redis使用异步线程在RocksDB中读写数据。毕竟，读写RocksDB的延迟无法与Redis的内存访问延迟相匹配。这也是为了避免在读写冷数据时阻塞Redis主线程。硬盘上冷数据的布局和管理委托给RocksDB。
3、集群管理的优化实践
关于集群管理方面，无论是Redis也好，MySQL也好，对资源的任何管理都可以用这个来总结，包括五个部分：资源申请，资源分配，业务上线，资源查询，资源变更。对于业务申请这一方面需要有一个业务唯一的标识，QPS、数据类型是怎样的，基于这些考察再对它进行分配、配置、部署。
总结
本文基于微博业务规模，分析Redis在微博内部分布在各个应用场景的使用与优化，主要有微博数据库的技术选型，基于微博业务场景的Redis改进方案，Redis在微博的优化实践（Cache Service服务化、解决Redis容量过大问题、集群管理的实践）。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
