基于 OB Cloud 的持久化缓存探索

挚文集团于2011年8月推出了陌陌，这款立足地理位置服务的开放式移动视频社交应用在中国社交平台领域内独树一帜。陌陌和探探作为陌生人社交领域的主流应用，涵盖了多种核心业务模块，包括直播服务、附近动态功能、即时通讯（IM）业务以及增值服务等。每个业务场景都具有其独特的特性和挑战。

1. 业务规模增长，现有架构存在瓶颈
   1. 针对当前公司的业务状况，陌陌面临的最显著挑战在于集群规模的不断增长。当单集群分片数量超过 1000 个，数据量超过 10TB，以及 QPS 超过 100 万时，现有的 Codis 架构和 Redis Cluster 架构已然无法满足需求，达到了其承载能力的极限。
2. 单机多实例互相影响
   1. 陌陌迫切需要解决单机多实例之间相互影响的问题，以确保各个实例的稳定运行和高效协作。这涉及到系统的整体稳定性和协同性，需要有针对性的优化和调整
3. 数据持久化能力不足
   1. 陌陌计划增强数据持久化的支持能力，以实现完整的数据持久化解决方案，以保障数据的完整性和可靠性。不仅仅局限于冷数据，而是要覆盖更广泛的数据类型，以确保数据的完整性和可靠性。这将是系统长期稳定性的一个重要保障。

陌陌与 OceanBase 开源团队共同打造了一个内部代号为 modis 的项目。该项目整体架构涵盖了接入层、数据结构层、缓冲层、存储层以及管理平面等多个层次。

值得注意的是，缓冲层在未来的规划中将用于有效解决热点读取及大 KEY 问题的挑战；而在存储层方面，陌陌将对其进行标准化抽象设计，构建出标准的 Storage 结构，以便能够灵活接入包括但不限于 OceanBase（OBKV）在内的多种存储解决方案。

总的来说，OceanBase（OBKV）-Redis 实现了性能的显著提升、更少的磁盘使用以及运维管理的极大简化。这主要得益于 OceanBase（OBKV）-Redis 的几个优势。

●  多租户隔离，解决单机多实例互相影响的困境；

●  存储成本更低。通过 Encoding 框架 + 通用压缩 ，进行表模型存储；

●  性能更高。将请求过滤直接下压存储，不用序列化以及反序列化，支持服务端 TTL。

1. 直播业务场景
   1. 在陌陌众多业务场景中，直播业务占据了显著位置，其特点就在于随时可能出现的流量突发场景。由于低延时和高并发的需求，直播场景对数据库系统的实时处理能力提出了较高要求。平台需要确保在大量用户同时在线观看和互动时，数据能够被及时、准确地处理和分发。
2. 附近动态功能场景
   1. 附近动态功能则涉及到用户的地理位置信息、活动轨迹以及社交关系等复杂数据。这类数据会迅速积累，并随着时间的推移形成大规模的数据集。数据具有明显的冷热分层特性，即某些数据在某一时刻可能会成为热点，如当某用户发布的帖子引发热议并成为热门话题时。这要求系统能够有效管理并快速响应热点数据的访问需求。
3. 即时通讯（IM）业务场景
   1. 核心特点是低延迟和高并发通信。信息的送达时间必须精确，对实时性有极高的要求。为了保证用户体验，应用程序需要确保消息能够即时、可靠地在用户之间传递
4. 增值服务场景
   1. 则主要侧重于数据的一致性和实时性。在处理用户购买、赠送虚拟物品或享受会员特权等操作时，系统需要确保数据的准确性并及时更新用户账户状态。同时，为了提供优质的增值服务，实时性也是不可或缺的因素，例如实时计算用户的积分、等级或者权益等。

1. 更高的性能
   1. OceanBase（OBKV）基于 Table 模型构建，与 Redis 数据结构持久化方案这个典型的表模型匹配，且性能比传统持久化存储更强 ，能构建更丰富的数据结构。OceanBase（OBKV）在大量写数据的场景（TPS 17000），响应延时在 2 毫秒以下。 CPU 使用率在 10% 以下。MemStore 的使用比例也是正常的，在 24% 以内，波动范围非常小。
2. 更高的稳定性
   1. OceanBase（OBKV） 基于 OceanBase ，存储引擎经过丰富的大规模 TP 场景验证，能提供高并发、低延时的能力。OceanBase（OBKV） 的多租户功能非常稳定性。同一个集群上，分别创建 OceanBase（OBKV）租户和MySQL 租户，压测显示，OceanBase（OBKV） 租户在负载较高的情况下响应始终正常， MySQL 租户也没有受到影响。从服务器层面来看，OceanBase（OBKV）租户的 CPU 负载是因为压测而上升，而 MySQL 租户并不受影响。
3. 简化架构，提升便捷性
   1. 能够便捷地通过 KV 接口将数据存入数据库，并运用 SQL 进行数据查询。OceanBase（OBKV）进一步增强了这一便捷性，它支持二级索引以及服务端 TTL 功能，这有助于显著简化上层服务架构的设计。
4. 节约 40% 存储成本
   1. 将 Pika 数据（总计 158GB）成功迁移到 OceanBase（OBKV）-Redis 集群后，存储占用空间显著减少至 95GB，这一举措带来了存储成本的显著优化，总体上节约了大约 40% 的存储成本。