《Redis核心技术与实战》学习总结（18）

【Redis】| 总结/Edison Zhou

新浪微博作为Redis深度用户，对Redis做了一些优化，一起来看看吧。
1微博对Redis的技术需求微博对Redis的三大具体需求如下

能够提供高性能、高并发的读写访问，保证读写低延迟；（高性能）
能够支持大容量存储；（大容量）
可以灵活扩展，对于不同业务能够进行快速扩容；（易扩展）

微博2019年的效果：100T+ 存储、1000+ 台物理机、10000+ Redis实例、万亿级读写、响应时间 20 毫秒2微博对Redis高性能的保障微博对Redis的基本性能改进可以分为两类：避免阻塞和节省内存。（1）避免阻塞

针对持久化需求，使用 全量RDB + 增量AOF复制 结合的机制，避免数据可靠性或性能降低的问题。（这也是Redis4.0之后提供的混合机制）
在AOF日志写入磁盘时，用额外的BIO线程负责实际的刷盘工作，避免AOF日志慢速刷盘阻塞主线程的问题。
增加了aofnumber配置项，用于设置AOF文件的数量，控制AOF写盘时的文件总量，避免写入过多的AOF日志文件导致的磁盘写满问题。
在主从库复制机制上，使用独立的复制线程进行主从库同步，避免对主线程的阻塞影响。

（2）节省内存微博的一个典型优化：定制化数据结构。优化内容：针对微博用户的关注列表场景，微博定制化设计了LongSet数据类型，它是一个存储Long类型元素的集合。优化剖析：首先，LongSet类型的底层数据结构是一个Hash数组，Hash 集合类型在保存大量数据时，内存空间消耗较大。其次，在并大请求压力很大的场景下，缓存实例从DB读取用户关注列表后用HMSET写入Hash集合，这个过程会降低Redis性能。3微博对Redis大容量的保障微博业务层要保存的数据经常会达到 TB 级别，因此对大容量存储的需求较强。优化内容：针对数据区分冷热度，把热数据保留在 Redis 中，而把冷数据通过 RocksDB 写入底层的硬盘。优化剖析：有些微博话题刚发生时，热度非常高，会有海量的用户访问这些话题，使用 Redis 服务用户请求就非常有必要。等到话题热度过了之后，访问人数就会急剧下降，这些数据就变为冷数据了。这个时候，冷数据就可以从 Redis 迁移到 RocksDB，从而节省Redis实例的内存来主要存储热数据。

举一反三：如果想实现大容量的 Redis 实例，借助于 SSD 和 RocksDB 来实现是一个不错的方案。RocksDB 可以实现快速写入数据，同时使用内存缓存部分数据，也可以提供万级别的数据读取性能。当前 SSD 的性能提升很快，单块 SSD 的盘级 IOPS 可以达到几十万级别。4微博对Redis扩展性的保障

微博有多条不同业务线，它们对Redis容量的需求各不一致，而且可能随时有扩容和缩容的需求。

优化内容：微博对Redis进行了服务化改造（RedisService），即使用Redis集群来服务不同的业务场景需求，每一个业务拥有独立的资源，互不干扰。同时，所有的Redis实例构成一个资源池，资源池本身也能轻松地扩容。

实现细节：在 Redis 服务化的过程中，微博采用了类似 Codis 的方案，通过集群代理层来连接客户端和服务器端。微博在代理层中实现了丰富的服务化功能支持。在服务化集群中，还有一个配置中心，它用来管理整个集群的元数据。同时，实例会按照主从模式运行，保证数据的可靠性。不同业务的数据部署到不同的实例上，相互之间保持隔离。