为企业液体冷却服务
|
计数 微博有很多计数场景，如用户纬度的关注数、粉丝数，微博纬度的转发数、评论数等。计数作为微博中一项很重要的数据，在微博业务中承担了很重要的角色。为更好的满足计数业务需求，我们基于 Redis 定制了内部的计数服务。 原生 Redis 为了支持多数据类型，需要维护很多指针信息，存储一份业务计数要占到约 80 个字节，内存利用率很低。为此我们定制了第一版计数器 Redis counter，通过预先分配内存数组存储计数，并且采用 doublehash 解决冲突，减少了原生 Redis 大量的指针开销。通过以上优化将内存成本降低到原来的 1/4 以下。(小编：又节约了 3 / 4 服务器……) 随着微博的发展，微博纬度的计数不断增加，在原来的转发数、评论数基础上，又增加了表态数，2013 年还上线了阅读数。 Redis counter 已不能很好的解决这类扩展问题：
为此我们又设计了改进版的计数器 CounterService，增加如下特性：
业务极致定制化时代(2012 - 2013) RedisCounter / LongSet 在某些特定的业务场景下，随着业务规模的持续增加， Redis 的使用又暴露出来一些问题，尤其是服务成本问题(小编：是省服务器的意思?)。为此结合特定的业务场景我们对 Redis 做了一些定制的优化。这里主要介绍一下在关系和计数两个业务场景下做的定制优化。
微博关系业务包含添加、取消关注，判断关注关系等相关的业务逻辑，引入 Redis 后使用的是 hash 数据结构，并且当作存储使用。但是随着用户规模的快速增长，关系服务 Redis 容量达到十几 TB，并且还在快速的增长，如何应对成本压力? 为了解决服务成本问题，我们把 Redis 的角色由 storage 调整为 cache。 这是因为随着用户数量的增长，业务模型由初期的热点数据不集中已经转变为有明显的冷热之分。对于关注关系变更、判断关注关系，hash 数据结构是最佳的数据结构，但是存在以下问题：
于是，我们定制了 longset 数据结构，它是一个“固定长度开放寻址的 hash 数组”，通过选择合适的 hash 算法及数组填充率，可实现关注关系变更及判断的性能与原生 Redis hash 相当，同时 cache miss 后通过 client 重建 longset 结构，实现 O(1) 复杂度回写。
通过定制 longset 数据结构，将关系 Redis 内存占用降低了一个数量级(小编：这该节约了多少服务器……发奖金了吗?)，同时保证了服务性能。 （编辑：广元站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
