前言极光从某种意义上说是一家数据公司。在整个公司的技术运营系统中，需要存储大量的KV数据。根据数据量、KV结构特点、数据更新频率、数据冷热、读写请求量及比例等因素，极光逐渐形成了三种不同的KV方案：CouchBase、Redis和Pika。下面主要介绍极光在大数据量/请求量场景下遇到的运维问题，以及服务性能、扩展性、数据备份和安全、运维保障工具等。极光使用的就是上面的KV组件。经验。1、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的内存占用只增不减，导致机器内存爆满，最终OOD。最后通过集群分裂暂时解决了问题，新集群也同步使用了更新后的版本。高可用主要有两个方面的高可用：一是有自己的集群方案，支持多副本模式。我们一般选择2副本模式，类似于一主一备的方案，保证没有单点故障；另一个是它有自己的持久化方案，可以设置为每隔一定时间异步向文件系统写入数据。因此，一般情况下，单个节点宕机对集群的可用性和性能影响有限，但一次故障超过2个节点，可能会丢失数据。易于配置和使用CouchBase安装后自带Web管理控制台，您可以在上面管理和操作集群、桶、索引、搜索等，大大简化了运维工作。这也是一般开源软件一般不具备的能力。商业产品在用户体验方面做得很好。当然，CouchBase也有一些明显的缺点：1、只能提供简单的KV存储模型，不支持复杂的数据结构（value支持json格式）。2.为了提高查询效率，KV中的所有Key都缓存在内存中，需要大量消耗Memory，尤其是每对KV附带的MetaData（一个KV存储的MetaData至少要消耗56Bytes）也要缓存在记忆中。在极光的实践中，经常会遇到MetaData占用内存50%以上的情况，这对内存容量提出了很高的要求，同时也导致成本很高。3、属于闭源产品，文档少，异常故障处理方法有限，存在一定风险；我们遇到过几次集群节点假死，数据量大的集群无法备份。任何有效的解决方案。至于核心和关键数据，放在CouchBase上是不靠谱的。这个需要根据业务场景来判断。目前极光使用CouchBase数据作为中间层数据。一旦发生数据丢失，可以从其他通道恢复回来。数据备份问题：当数据量达到一定规模时，使用CouchBase自带的备份工具会备份失败。与CouchBase的官方沟通也没有回应。针对大型CouchBase集群下rebalance假死的问题，我们后期将大集群拆成若干个小集群，实现压力分散和运维管理，但是数据分片需要在业务端进行处理需要业务介入，对业务方有一定的侵入性。监控告警生态相对成熟，数据通过对应的Exporter上传到Prometheus也相对简单方便。我们设置如下主要告警规则，方便及时发现问题：1.Bucket内存使用率超过85%2.CouchBase集群节点CPU使用率超过90%3.xdcr同步失败4.CouchBase节点异常/重启2.Redis实践Redis是知名的开源KV存储，业界应用广泛，极光也大量使用Redis。AuroraRedis规模目前AuroraRedis的资源使用量约为30TB，实例总数约为7K。Redis生态丰富。由于它的流行，有很多实际案例。网上有很多文章和教程。生态很好，运维和研发人员也很熟悉。与CouchBase和Pika相比，这一点真的非常重要。不仅可以节省大量的沟通成本，还可以直接复用很多成熟的方案，让排错和优化变得更简单。在基础组件的选择上，成熟度、通用性和丰富的生态确实很重要。高性能也是因为全内存运行，Redis的性能非常高。我们实际使用中单个Redis实例的峰值性能可以达到50000QPS（这是公司的峰值标准，达到这个值我们认为已经达到了瓶颈，但是实际性能测试比这个要高），如果按照单机8个实例，理论上可以达到40万QPS，这个数据相当惊人。当然，由于redis的单进程+阻塞模型，在遇到慢指令时，整体的延迟会增加。我们需要在应用架构设计和运维方面考虑这一点，比如在业务低峰期进行一些高延迟的操作。.Redis性能测试：在主从模式下，我们一般使用sentinel模式，一般不会有问题；但是有一次我们出于提高可用性的目的，将一组sentinel从3个节点扩展到5个节点，然后发现这个sentinel所监管的redis实例出现了大量的延迟告警。后来调查发现和扩容到5个节点有密切关系。进一步排查slowlog发现sentinel发送的INFO命令导致redis实例的响应延迟增加。在这方面要特别注意哨兵检测带来的资源消耗。在高QPS压力下，任何额外的压力都非常敏感。自包含的集群模式Redis有自己的Redis-Cluster架构，在一定程度上解决了超大规模数据集的存储问题。Redis集群性能测试：但由于其分散的架构模型，在大规模集群下难以运维和数据迁移。在极光，我们目前最大的Redis-Cluster集群有244个主从节点，总数据量超过800G，峰值QPS可达8M（八百万QPS）。压力挺大的，运维压力也挺大的。.第一：扩容困难，扩容带来的slot迁移在高QPS的压力下，导致客户端收到大量MOVED返回，最终导致业务端出现大量错误；第二：扩容时间很长，从244个节点到272个节点，花了我们一周的时间，浪费了我们很多人力资源。渐渐地，我们形成了一套Redis-Cluster应用的最佳实践。首先，严格控制Redis-Cluster集群的规模，master节点不超过100个。其次，前期我们通过业务端的数据切分，将数据分布到不同的Redis-Cluster集群中；公司逐渐通过自研JCache组件实现宏集群，将多个原生的Redis-Clusters组合成一个宏集群；JCache是??根据Key规则来做hash的，相当于多了一层proxy。当然这也带来了一些新的问题需要解决，比如后端Redis-Cluster的拆分和数据重分片的问题，也增加了JCache的复杂度。JCache宏集群方案：监控也是使用Exporter采集数据给Prometheus。这个生态非常完善，现成的解决方案可以直接复用。我们为Redis设置了以下告警规则：1.内存使用率告警（为每个redis应用自定义，默认90%）2.客户端连接数告警（默认2000）3.Redis实例宕机告警4.哨兵发生主从切换告警5、应用整体qps阈值告警6、特定rediskey监控性能优化：1、关闭THP2、屏蔽高危命令（keys/flushall/flushdb等）3、部分数据频繁过期的redis应用，通过调整hz参数，加速过期键的清理，尽快回收内存。一些清理次数从默认的每秒10次增加到每秒100次，但是在大QPS请求下，会有性能影响。4.对于一些对内存要求高，性能要求稍低的Redis应用，通过调整数据底层存储结构来节省内存，比如调整hash-max-ziplist-entries/hash-max-ziplist-value3.Pika实践Pika是一款兼容Redis协议的国产开源KV存储。底层是基于RocksDB的存储引擎，支持多线程，属于磁盘KV存储系统。比较适合数据量极大（比如TB级）但QPS要求不是特别高的场景。目前AuroraPikascalePika的数据量约为160T。高性能从我们使用NVMeSSD作为存储介质实测来看，单机（8核32G）峰值达到18WQPS是没有问题的。在实际使用场景中，QPS的峰值可以达到10W而不影响业务。目前公司自建IDC采用NVMeSSD。最大的ops约为7.6W。生态不成熟。国产开源软件受众小。软件不是特别成熟，功能迭代变化很快，从2.X版本到3.X版本。版本方面，根据社区反馈，我们做了很多改进，目前基本稳定使用3.2.X版本。注：新应用基本以3.2.x版本为基础，部分遗留历史应用因资料重要暂未升级360公司继续负责维护。从QQ群的反馈来看，似乎核心开发者越来越少，项目前景有些黯淡。这也是很多小众开源软件的通病。软件本身很容易受到公司政策或一些核心人员变动的影响。2020年12月最新版本的Pika发布，快一年过去了。代理层因为Pika只有主从模式，而我们的数据量动辄几TB，QPS动辄几十万，所以实际使用中需要在前面加一个代理层做hash分片工作.目前最大单实例达到2T，实际QPS达到10万，读写实例比例1:3，满足写少读多的场景。标配SSD无论从官方推荐还是实际使用，鼠兔的硬盘都标配了NVMeSSD硬盘。与普通SSD磁盘相比，它们提供更高的IOPS和吞吐量，以及更低的读写延迟。在鼠兔生产环境中，NVMeSSD的峰值IOPS可达5万，而普通SASSSD盘只有1万。性能提升还是很明显的。对比价格的差异，性能的提升就非常大了，更何况是对比内存。串行主从问题Redis可以支持并实现主从串行关系。我们在使用Pika的时候也做过类似的部署，但是出现了一个严重的问题，导致我们丢失了数据。Pika对于主从系列模式下数据同步状态的管理非常简单粗暴。只能看到slave和master建立了连接，但是数据同步是否完成，有没有丢失数据，需要应用层去处理。这也是我们研究代码后得出的结论。一方面是缺乏文档。另一方面也说明，在使用开源软件时，不要想当然，要经过严格的确认和测试，否则会带来很高的代价。注意：鼠兔从3.2.X版本开始不再支持串口主从设置。所有slave都要从master同步数据，这会对master节点造成一定的读取压力。仍然可以通过Exporter收集监控告警监控信息并上传到Prometheus。比较简单明了的Pika告警规则设置如下：1、Pika实例进程告警2、Pika连接数告警3、Sentinel主从切换告警4、JCache慢查询告警5、Pikamaster写数据失败告警性能参数：1.auto-compact自动压缩参数，针对过期数据量大的应用2.root-connection-num保证客户端在连接数满后仍然可以通过pika本地连接3.压缩算法改为lz4，性能好，压缩比高。第四，后续规划。极光目前的KV存储经历了这么多年的演进，足以满足现在的需求，但是仍然存在扩容不方便不顺畅、大规模集群性能瓶颈、性价比等问题；未来，我们将专注于业务赋能，将KV存储做成一套更具适应性和灵活性的存储服务。我们可以考虑引入存储计算分离、冷热分层等技术，在扩缩容、性能优化、性价比等方面都达到了更高的水平。
