Redis在新浪微博的应用：其一，如何构建类微博的亿级社交平台；其二，用最少的机器支撑万亿级访问，微博6年Redis优化历程。
1. 基础数据的存储
已发表微博可以使用Hash来存储，微博ID作为key，内容、发布时间等作为key存储到hash中；
Feed流可以使用有序集合sorted set，用户ID作为key，timestamp作为score，值关联微博ID，则可以按时间顺序获取时间线。具体的微博内容通过ID做进一步的查询；
关注/粉丝列表，同样可以使用zset实现，以关注列表为例。key为当前用户ID，score和member分别为timestamp和关注的用户的ID。
2. 如何扩展读性能
单台redis服务器每秒支撑到10k，微博这种规模的网站，并发量远远超出单台redis的最大值。文中提到了一些扩展前的优化原则，比如选择合适的数据结构、合理大体积对象的压缩算法等，在此不再赘述。
提升redis的读取能力最便捷的做法是增加从服务器提供额外的读查询能力，但要确保使用只读从服务器的时候，只对redis的主服务器进行写入。文中还提到一个棘手的问题——主服务器下线。主服务器同时向多个从服务器发送快照，可能会耗尽主服务器带宽，延迟增高，可以通过增加中间层解决。这种方案也增加了故障转移的难度。另一种优化带宽的做法是压缩数据量——使用带压缩的SSH隧道连接。文中还特意提到，注意将SSH设置成断线重连。
3. 如何扩展写性能
当需要存储的数据量单台机器无法承载之后，可以通过集群分割存储。文中提到的这些方法通用性很强，也可以在单台redis上获得写吞吐量提升。
仍然是给出了一些降低内存的编码原则，比如使用锁替换WATCH/MULTI/EXEC事务和AOF模式下的命令长短对磁盘写入的影响。
如果预计写入量每6各月增加4倍，则256个分片可以确保接下来的两年不用担心容量增长。但是也有预先分片得不偿失的情况，文中建议但台机器运行多个redis实例，每个作为一个分片，并且监听端口和写入的快照或AOF文件要确保不同。系统性能卡在redis的单线程设计并拥有更多的网络资源时，可以考虑单台多实例。
4. 复杂的业务场景
针对微博这类社交网站，找出读取和写入数据的差别，分清常用和不常用数据的差别对性能提升很重要。
已发布的微博基于key散列做分片，分片到集群，还要将老一些的数据存储到硬盘DB中。
信息流的长度比较短，个人发布的信息流也可以通过限制长度来解决。但是关注/粉丝列表的长度也有极其长的情况。关注列表可以通过限制解决，但是有的用户粉丝数量庞大，仍然没法解决。微博的做法是将存储粉丝的soted set分片。信息流分片的对象是key，而这里是粉丝数据。
5. 高可用优化
问题一，持久化方面，单机多实例同时开始持久化，copy-on-write，内存耗尽，redis崩溃；
问题二，主从同步方面，切主操作全量复制导致的流量暴增；
持久化的问题是通过定时错峰解决的，主线程AOF写入导致的服务阻塞通过BIO线程解决。
主从同步借鉴了MySQL的复制机制，而对待版本升级问题，采用的是核心逻辑封装动态库方案。
6. 定制化
关系服务（添加、取消关注），成本推高之下，数据冷热分明之后，redis的由storage调整为cache。为了提升内存使用率，自定义数据结构存储关注关系和计数。
7. 服务化
由于数据迁移、HA问题、路由规则等，开发平台化的redis服务中心，集数据、代理、客户端和集群配置于一体。
网友评论