前言
极光从某种意义上讲，是一家数据公司。在整个公司的技术经营体系中，须要存储大量的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存储做成一套适应性更强、更灵便的存储服务，可能思考引入相似存算拆散、冷热分层等技术，在扩缩容、性能优化、性价比等维度上更上一层楼。