前言
极光从某种意义上讲，是一家数据公司。在整个公司的技术经营体系中，须要存储大量的 KV 数据。依据数据量、KV 构造特点、数据更新频率、数据冷热、读写申请量和比例等因素，在极光逐步形成了 CouchBase、Redis 和 Pika 三种不同的 KV 解决方案。
以下咱们次要是从大规模数据量 / 申请量场景下碰到的运维难题，以及服务的性能、可扩容性、数据备份与平安、运维保障工具等方面介绍一下极光在应用以上 KV 组件的实践经验。
一、CouchBase 实际
极光 CouchBase 规模
CouchBase 以后总使用量大概在 6.5T 左右；单个集群最大 25 台（16 核 128G 内存）。
CouchBase 是一个非关系型数据库，它实际上是由 couchdb+membase 组成，所以它既能像 couchdb 那样存储 json 文档，也能像 membase 那样高速存储键值对。
在极光咱们次要用它做 KV 存储，次要有以下几个特点：
速度快
因为是放在内存中的数据库，所有的读写操作都是间接操作内存，因而速度十分快。极光数据量最大的集群规模约 25 台机器（16 核 128G），能够提供 1.5TB 的可用内存。读写压力最大的集群，大略是 8 台机器，然而须要抗住 100 万的 QPS，单机能够抗住 10 万以上的 QPS，性能相当强悍了。
与官网声称的性能与节点数的线性关系不同，理论应用中发现，超过 40 个节点的集群，在扩缩容、故障节点替换、集群稳定性方面存在显著的问题，在扩缩容、替换节点的时候，集群容易进入假死的状态，在管制台上没有任何反馈，客户端断断续续呈现超时或者谬误的返回后果。这个过程无奈疾速主动复原，在极光相似的故障最长的一次继续了 3 个多小时，最终咱们是停掉了业务才修复的。
另外有一次故障，发现次要起因 CouchBase 内存占用只增不减，导致机器内存爆满，最终被 oom。最终通过进行集群拆分临时解决了问题，新集群也同步应用更新的版本。
高可用
次要有两个方面的高可用：一个是它自带集群计划，反对多正本模式，咱们个别是抉择 2 正本模式，相似一主一备的计划，这样能够确保没有单点故障的问题；
另一个是它自带长久化计划，能够设置定时把数据异步写到文件系统上，所以在个别状况下繁多节点的宕机，对集群的可用性和性能影响无限，然而一次性故障超过 2 个节点，就有呈现数据失落的可能性了。
配置使用方便
CouchBase 装置后自带 web 治理台，能够在治理台上对集群、桶、索引、搜寻等进行治理和操作，大大简化运维的工作。这也是个别开源软件所广泛不具备的能力，商业化的产品对于用户体验的确做得很好。
当然，CouchBase 也有一些显著的毛病：
1、只能提供简略 KV 存储模型，不反对简单数据结构（value 反对 json 格局）
2、为了晋升查问效率，KV 中的 Key 全副都缓存在内存，须要耗费大量内存，特地是每一对 KV 所附加的 MetaData（一个 KV 存储至多耗费 56Bytes 的 MetaData）同样缓存在内存中。在极光的实际过程中，常常碰到 MetaData 超过 50% 内存占用的状况，对内存容量提出高要求，也导致老本较高。
3、自身是闭源产品，文档较少，出现异常故障解决伎俩无限，存在肯定的危险；咱们碰到过好几次的集群节点假死，还有数据量大的集群无奈进行备份的状况，没有找到任何无效的计划。那么对于外围、要害数据，放在 CouchBase 上进行存储是不牢靠的，这块是须要依据业务场景来判断的，目前极光应用 CouchBase 的数据都是中间层数据，一旦产生数据失落，都能够从其余渠道复原回来。
数据备份问题：
对于数据量达到肯定规模，应用 CouchBase 自带的备份工具进行备份时就会呈现备份失败的状况。与 CouchBase 官网沟通也没有回复。
针对 CouchBase 大规模集群下的 rebalance 会存在假死的问题，前面咱们把大集群拆解成了数个小集群，实现了压力的扩散和运维治理的扩散，不过须要在业务侧做数据的分片解决，须要业务染指，对业务方存在肯定的侵入。
监控和告警生态绝对比拟成熟，通过对应的 Exporter 获取数据上传到 Prometheus，整体比较简单不便
咱们设置了以下的次要告警规定，便于及时发现问题：
1、bucket 内存应用超过 85%
2、CouchBase 集群节点 CPU 应用超过 90%
3、xdcr 同步失败
4、CouchBase 节点产生异样 / 重启
二、Redis 实际
Redis 是出名的开源 KV 存储，在业界应用极为宽泛，极光也在大量应用 Redis。
极光 Redis 规模
以后极光 Redis 资源使用量大概在 30TB 左右，实例总数大略在 7K
生态丰盛
Redis 因自身的知名度，实际案例十分多，网上的文章和教程非常丰盛，有一个很好的生态，运维和研发人员也十分相熟。这块比照 CouchBase 和 Pika 来说，真的十分重要，岂但能够节俭大量的沟通老本，还能够间接复用很多的成熟解决方案，排查故障和优化工作也更加简便。
在抉择根底组件这块，成熟、通用、生态丰盛真的十分重要。
高性能
同样因为全内存操作，Redis 体现出相当高的性能，咱们理论应用中单 Redis 实例峰值性能能够达到 5 万 QPS（这是公司的峰值规范，达到该值咱们就认为曾经达到瓶颈了，但理论性能测试要高于此），如果依照单机 8 个实例，实践上能够达到 40 万 QPS，这个数据相当惊人了。当然，因为 redis 的单过程 + 阻塞模型，碰到慢指令就会导致提早整体上涨，这块咱们在利用架构设计和运维方面须要特地思考，比方在业务低峰期再进行一些高提早的操作。
redis 性能测试：
主从模式下，咱们个别都应用哨兵模式，这个一般来讲不会有什么问题；然而有一次咱们怀着进步可用性的目标，把一套哨兵从 3 节点扩容到 5 节点，之后发现该哨兵监管的 redis 实例呈现大量的提早告警，起初排查发现和扩容到 5 节点密切相关，进一步排查 slowlog 发现是哨兵发送的 INFO 指令导致 redis 实例响应提早减少。在这块，要特地留神哨兵的探活导致的资源耗费，在高 QPS 压力下，任何一点新增的压力都非常敏感。
自带集群模式
Redis 自带了 Redis-Cluster 架构，在肯定水平上解决了超大规模数据集的存储问题。
Redis cluster 性能测试：
不过，因为其无核心的架构模型，在大规模集群下运维和数据迁徙较为艰难。在极光，咱们以后最大的 Redis-Cluster 集群达到 244 个主从节点，总共超过 800G 的数据量，峰值 QPS 能够达到 8M（八百万 QPS），压力相当大，带来的运维压力也是相当大。
首先：扩容比拟艰难，扩容导致的 slot 迁徙在大 QPS 压力下，导致客户端收到大量 MOVED 返回，最终导致业务端大量报错；
其次：扩容工夫十分长，从 244 个节点扩容到 272 个节点，破费了咱们一个星期工夫，节约了咱们很多人力资源。
逐步地咱们造成了一套 Redis-Cluster 的利用最佳实际
首先、严格控制 Redis-Cluster 集群规模，主节点不超过 100 个。
其次、后期咱们通过在业务端做数据切割，将数据分布到不同的 Redis-Cluster 集群；逐步地公司通过自研 JCache 组件实现宏集群，将多个原生的 Redis-Cluster 组合成一个宏集群；在 JCache 做基于 Key 规定的 hash，相当于多了一层代理。当然，这样也带来一些新的问题须要解决，比方后端 Redis-Cluster 的决裂和数据从新分片的问题，也减少了 JCache 的复杂度。
JCache 宏集群计划：
监控同样是应用 Exporter 收集数据到 Prometheus，这块生态非常欠缺，间接复用现成的计划即可。
咱们针对 Redis 设置了如下的告警规定：
1、内存使用率告警（每个 redis 利用自定义，默认 90%）
2、客户端连接数告警（默认 2000）
3、redis 实例 down 告警
4、哨兵产生主从切换告警
5、利用整体 qps 阈值告警
6、特定 redis key 监控
性能优化：
1、敞开 THP
2、高危命令屏蔽（keys/flushall/flushdb 等）
3、局部数据频繁过期的 Redis 利用，通过调整 hz 参数，放慢过期 key 清理，尽快回收内存，有一些从默认每秒清理 10 次进步到 100 次，然而在大 QPS 申请下，会有性能影响
4、对局部内存需要高，性能要求稍低的 Redis 利用，通过调整数据的底层存储构造，来节俭内存，如调整 hash-max-ziplist-entries/hash-max-ziplist-value
三、Pika 实际
Pika 是国内开源的一套兼容 Redis 协定的 KV 存储，底层基于 RocksDB 存储引擎，反对多线程，属于磁盘 KV 存储系统，比拟实用于数据量特地大（例如 TB 级别）然而 QPS 要求不是特地高的场景。
极光 Pika 规模
Pika 以后数据量大概在 160T 左右。
性能较高
从咱们应用 NVMe SSD 作为存储介质实测下来，单机（8 核 32G）峰值达到 18W QPS 是没有问题的，理论应用场景下峰值 QPS 能够达到 10W 而不影响业务。
以后公司自建 IDC 应用 NVMe SSD 最大的 ops 在 7.6W 左右
生态不算成熟
国内开源软件，受众不算大，软件不是特地成熟，性能迭代变动较快，从 2.X 版本疾速迭代到 3.X 版本，依据社区反馈而做了很多改良，目前咱们根本稳固应用 3.2.X 的版本。
注：新利用根本都是基于 3.2.x 版本，还有局部遗留的历史利用因为数据比拟重要，临时没有降级
最近一年因为我的项目变更，Pika 仿佛募捐给了国内某个开源基金会，不再由 360 公司持续负责保护，从 QQ 群的反馈来看，外围开发人员仿佛越来越少，我的项目前景有一点黯淡。这也是很多小众开源软件的常见问题，软件自身很容易因为公司政策或者某些外围人员的变动而受到较大影响。
Pika 最近一次发版本还是在 2020 年 12 月，曾经快过来一年工夫了。
代理层
因为 Pika 只有主从模式，而咱们的数据量动不动就好几个 T，QPS 数十万，所以咱们在理论应用时须要在后面加了一层代理层来做 hash 分片工作。目前单个实例最大达到了 2T，理论 QPS 达到 10 万，读写实例比例 1:3，满足写少读多的场景。
标配 SSD
无论从官网倡议还是理论应用，Pika 的磁盘咱们都标配 NVMe SSD 磁盘，相比一般 SSD 磁盘，提供更高的 IOPS 和吞吐能力，更低的读写提早。Pika 生产环境，NVMe SSD 咱们峰值 IOPS 能够达到 5 万，而一般的 SAS SSD 磁盘也就 1 万，性能晋升还是很显著的，比照价格的区别，性能晋升十分多，更不用说相比内存了。
串联主从问题
Redis 能够反对和实现主 - 从 - 从的串联关系，咱们在应用 Pika 的时候也做过相似的部署，后果呈现了重大问题，导致咱们失落了数据。Pika 在串联主从这种模式下对于数据同步状态的治理非常简略粗犷，只能看到 slave 和 master 已建设连贯，然而数据是否同步结束、是否有数据缺失都须要应用层去解决。这也是前面咱们钻研代码得进去的，一方面是文档的缺失，另一方面也阐明了在应用开源软件时不要天经地义地认为是怎么样，而是要通过严格的确认和测试，否则带来的代价是十分大的。
注：Pika 从 3.2.X 版本后就不再反对串联主从的设置了，所有 Slave 都必须从 Master 同步数据，会对 Master 节点造成肯定的读压力。
监控和告警
监控信息还是能够通过 Exporter 收集并上传到 Prometheus，比较简单清晰
Pika 的告警规定设置如下：
1、Pika 实例过程告警
2、Pika 连接数告警
3、哨兵主从切换告警
4、JCache 慢查问告警
5、Pika master 写数据失败告警
性能参数：
1、auto-compact 主动压缩参数，针对存在大量过期数据的利用
2、root-connection-num 保障客户端把连接数占满后依然能通过 pika 本地连接上
3、压缩算法改为 lz4, 性能好，压缩比高
四、后续布局
极光目前的 KV 存储经验了这么多年的演进，满足以后需要是足够的，然而依然存在扩容不不便、不平滑，大规模集群性能瓶颈、性价比等问题；将来将重点投入在对业务的赋能上，将 KV 存储做成一套适应性更强、更灵便的存储服务，可能思考引入相似存算拆散、冷热分层等技术，在扩缩容、性能优化、性价比等维度上更上一层楼。