华为刘腾：华为终端云Cassandra运维实践分享

点击此处观看完整活动视频

 

各位线上的嘉宾朋友你们好，我是来自华为消费者BG云服务部的刘腾，我今天给你们分享的主题是华为终端云Cassandra运维实践。和前面王峰老师提到的Cassandra在360中使用场景不一样，我今天主要带来的是运维相关的内容。在去年7月，咱们开发部的吴太银也在Cassandra社区作过一次分享，讲到了Cassandra在华为的一些应用，包括一些在华为遇到一些线上问题的定位和处理经验。今天我就和你们讲一下运维这一块。

 

这是我今天要分享的内容，重点是第二部分：咱们在运维中遇到的一些问题。

华为终端云Cassandra使用场景和规模介绍

咱们首先介绍下华为终端云在Cassandra使用的状况，华为在2014年的时候开始使用Cassandra，这在国内也是相对比较早的。如今通过6年的发展，咱们达到了比较大的应用规模，全球节点数已经超过3万，总存储量超过20PB，还有最大的这个表记录数三千亿以上，这个量都是比较大的。

至于为何华为终端云大量地使用Cassandra，这主要归功于Cassandra自己的一些数据库优点，好比它高可用、极致在线（应用无感）、可调一致性、多DC(datacenter)部署的特性。此外对运维方面也是很友好的，还有一些运维的工具等等。所以Cassandra在华为终端云这一块应用的是比较多的。

咱们主要将Cassandra用在一些结构化的数据存储，像咱们的社交风控、IoT等场景都用到了。如今咱们也有多个版本，最先的时候咱们用的是Cassandra 2.x的版本。这是咱们华为终端云的一个使用状况。

运维面临的主要挑战

咱们在终端云这一块业务发展的这么快，Cassandra规模这么大，咱们不免也会遇到一些问题，主要体如今如下这四个方面。

1. 可靠性：早期咱们是IDC机房，这种自建的托管的机房。咱们须要维护这些硬件设备、处理硬盘损坏的这些问题。还要考虑到机房AZ级的这种故障，或数据一致性、备份的问题。而后在使用上，现网还会碰到Cassandra的一些自己的问题，像是大Key和热Key的问题。

2. 数据库问题和风险管理：在平常的一些变动管理的问题尤为是一些高危操做。

3. 资源和成本管理：此外是资源成本这一块。咱们有这么多节点，如何管理是个问题。

4. 运维效率： 咱们人数有限（2～3）人，那如何提升运维效率。 

 

我会主要围绕以上这些话题来说，当遇到这些问题时咱们华为终端云是如何作的。

华为终端云Cassandra运维体系介绍

其实总体也是一个过程，咱们一开始也是慢慢地摸索过来的。而后咱们才有一些比较规范的运维流程，由于运维仍是很注重流程的，就是按流程去正确的作事，因此流程很重要，咱们包括一些变动流程、问题处理流程等等。你们也都据说过，华为公司自己就很注重流程的规范性、流程的建设。

咱们本身通过这几年的发展，把平台也建起来了，但咱们依托一些大平台， 好比说监控的，包括部署和自动发布的这种平台。还有咱们本身专门开发的Cassandra运维管理的平台，像一些作数据库自动化变动的平台。咱们会在后面重点介绍在可靠性、风险管理、运维效率等方面的挑战。

运维实践经验分享之可靠性：大集群拆分

首先咱们会讲一下可靠性这一块，在咱们的大集群中会遇到一些问题，这是在咱们现网里发生的一个例子：

咱们有一个超过450节点的大集群，它的Token总数也比较大，超过10万。但在咱们当时扩容的过程当中，业务全部的节点负载都很高，业务也受到影响。过后咱们对其进行了分析，发现原始Cassandra客户端请求、计算路由的时候会有一个读写锁。这本质上当有节点在扩容的时候，它也会更新路由信息。若是你更新比较慢，锁一直没被释放，这会致使你后面的读写也拿不到锁，这样的话就会致使你的请求一直出差，最终你的服务器负载要持续升高，那就出现问题。

对于这种问题，咱们就有一些建议。一个是你的控制集群的规模，尤为是虚拟Token数量。咱们原来最先的时候设的Token number数的是256，若是节点一多，那Token总数就会很大，这便会影响它自己的计算性能。所以咱们建议Token数不要超过10万。其实咱们在社区上也找到过一个case，跟咱们这个状况差很少，他当时也遇到这个问题。 他好像是Cassandra 3.x的版本，咱们是当时仍是Cassandra 2.x的版本。

而后对于一些新的集群，若是你的数据很大，要提早作好容量规划，尽可能不要让集群中单节点负载过大，不要等到过后再去拆分。我看到以后Cassadra 4的版本优化了Token的分配和管理机制，那在后面是能够尝试升级到Cassandra 4的版本的。

这里我实际上是经过这个案例来说为何要作大集群拆分，其实若是集群太大的话，它还会带来一些问题，好比说你这个扩容会比较慢，由于你每次只能扩一个节点，对不对？你的集群一大，你扩容确定会比较慢，还有就是数据修复也会比较慢。

因此对于这种大集群，咱们是建议要控制规模。虽然理论上Cassandra也许能够支持几百上千个节点，但若是你真正到那么大的规模，我以为对于运维来讲是一个很是大的挑战，对系统稳定性也有必定影响。

咱们原来有一个业务集群就作了一个拆分，那怎么拆？这几年来，咱们的一些早期业务可能有多个服务，这些服务可能就共用了一个集群，而后经过不一样的Keyspace和Table来区分。规模太大以后怎么办？咱们建议它按照服务维度和keyspace表维度进行拆分。

咱们这里面有几点要注意的。存量的数据，咱们能够经过打快照sstableloader作一个迁移。而后增量数据咱们能够用到Kafka，前提是咱们要改一下咱们的驱动，要支持双写。双写就是你在写你原集群的时候，你要把数据主键写到kafka里面，这样的话咱们会有一个消费的程序。我去Kafka里面把主键查出来，去原集群反查，把数据写入到新集群，经过这样的方式作到一个全量加增量的数据同步。作完以后，咱们可能还要作一个一致性的对比。这就是一个大集群拆分的思路。

运维实践经验分享之可靠性：多AZ部署

以前咱们提到由于可靠性在IDC机房面临的一些问题，后面就慢慢迁移到云上了。其实云上也会面临一些问题，好比说你这么大的集群，你会有反亲和的问题。云上那些虚拟机你是看不到它分布在哪一个物理机上面的，那就须要用到反亲和组，你不可能把你的集群机器都独立放到一台物理机上，由于公有云实际上是有可能会存在这种状况的。若是有物理故障，它会影响到集群的可靠性。如今有不少云厂商都有专属物理主机，若是你集群规模都太大，你本身买单独虚拟机，而后利用Cassandra自己的机架感知，从而让Cassandra将不一样副本分布在不一样的机架上。

其次就是如今不少公司推荐并在使用的，也就是3AZ部署，在这里咱们会介绍咱们的场景的主管模式，咱们在消费和终端里都有用到。好比图中的双AZ副本，它的优势也很明显，你若是client的话，你正常只会访问本地DC（图中对应的是AZ），但问题是成本高，还有要本身考虑故障切换。

3AZ3副本的优势是，咱们能够把每一个AZ当一个虚拟rack来看待，那读写一致性就能够用QUORUM，这样成本就会低一些，任意AZ的故障也不会影响可用性。但它也有的缺点，你由于跨AZ随机访问会增长访问时延，这取决于你AZ间网络时延。通常像公有云厂商AZ间时延说的是不高于两毫秒，但若是你的业务对这种时延比较敏感的话，那可能这种并非特别适合。对它的性能可能也会有必定的降低，咱们测试出来大概是会下降15%～20%。

如今不少初创型公司都会部署到公有云的服务器上，大家能够尝试一下这种3AZ部署方式，作一下性能测试看看效果如何。

在Cassandra原来是一个DC的状况下，若是要拓展到多个DC，咱们要考虑如何同步这些数据。

首先咱们既能够用nodetool rebuild也能够用sstableloader。这两种方式也有不同的地方，build只能从原AZ(DC)其中的一个副本节点获取数据, 若是三个AZ副本不一致，那有可能没法获取一致的数据，咱们所以建议在同步以前要作repair操做。sstableloader的问题是拷贝的数据量是原来的三倍，所以磁盘须要申请额外的存储空间，数据迁移完成后还要用nodetool cleanup删除冗余的数据。这两种方式能够根据你的使用状况来选择性的使用。

运维实践经验分享之可靠性：数据一致性

接着咱们来谈一下数据一致性所遇到的一些问题，虽然咱们使用quorum或local quorum，但这也是Cassandra会面临比较多的一个问题。由于你始终会面临坏盘、节点宕机，或某些公司出现的集群网络、负载不稳定等问题。这些都会致使数据不一致。若是你经过本身的DBA管理这些物理机，这样的成本仍是比较高的。如今不少都是在云上的，包括咱们也是经过云将数据迁移到虚拟机。将硬盘换成云硬盘，数据一致性相对就会好不少了。固然，它也会带来一些问题，好比成本会有小幅上升。还有hint的保留时长也能够从默认的3小时改成24小时，这对磁盘的存储增长不会很大，若是你的集群网络环境比较稳定的话，就不会有什么问题。

最后就是要对数据作一个按期地修复，也就是所谓的repair操做。你通常两周到一个月作一次，其实不会有太大的问题。但不用作的太频繁，由于修复太频繁会占用过多资源。同时你要控制修复段足够的小，并发量要控制好，尽可能不要影响在线的业务。

咱们其实有多个场景，用的两个最直接的部署，咱们也会按期去作一个对比。在华为终端云这里，咱们早期也用了ES(ElasticSearch)来弥补Cassandra二级索引的不足，但这也会带来一些问题。由于ES和Cassandra数据会有不一致，你要按期作一些检查修复。

运维实践经验分享之可靠性：数据备份

接下来咱们介绍一下数据备份，这是为了一些极端的场景，其实大部分状况下你是用不到的。但对于咱们这么大的规模来讲，有不少重要核心数据，所以咱们必定是要考虑这种备份，这里有几个场景，我就不详细介绍了。备份其实仍是基于原生Cassandra的快照(snapshot)的能力。它其实本质上就用的是Hard Link，这样咱们便会把这数据备份到咱们的OBS存储中。目前咱们RPO能够作到5分钟之内，RTO大概就是根据数据的下载的时间，通常1T数据大概要2~3小时。

我以为对于一些小公司和初创型公司来讲，你要关注的是你要出现了误操做怎么办？你可能认为你的数据不须要备份到OBS这种程度，但你可使用Cassandra自己自带的特性，你能够把配置文件里的配置项都打开，如在作TRUNCATE的时候作自动快照。这我以为是Cassandra的对运维来讲很是好的一个的地方。若是你真的误删了，其实硬盘上并没删除。你仍能够经过快照很快地进行恢复，这也不须要什么太大的成本。无论是开发人员、仍是运维人员，我强烈建议你们在后面使用的时候打开这些开关，防止一些极端的状况。

运维实践经验分享：Cassandra数据库风险治理

下面列了一些咱们数据库现网的一些问题管理中的使用规则。有些开发同事可能认为这些规则限制了他，但这些机制实际上是Cassandra自己的一些约束。若是你突破这些约束，你的现网可能会出现一些不可预知的问题。假如你在设计schema阶段引入了问题，到后期一旦出现问题，在短期内是没法解决的。你要从新优化schema，作出新的版本，这会花费很长的时间。

所以在咱们这里会先立规则。你们在开发的同时，必定要知道这些规范，在开发阶段就要减小这些问题。在咱们华为，若是你有业务要接入Cassandra，你要按照这些规则自检一下，咱们作一个简单的评审，若是没有问题，咱们就会给你提供一些建议方案。若是你的分区键在你的表结构Schema设计上存在一些问题，咱们会给出一些建议，让你优化以后再接入现网。若是后期实在仍是有漏掉的，咱们经过一些巡检，把这些问题找出来，会通知到业务，跟业务一块儿去作一些优化。

我看到DataStax公众号上面有一篇文章也讲的很是详细，有哪些注意事项。我认为每一个开发的同事，包括运维的同事都要认真熟读一下。

运维实践经验分享：热key案例

这实际上是咱们一个热Key的案例，我就不详细讲了。其实你在设计Schema的时候便要考虑你的场景是否存在热Key，能规避则尽可能规避，若是规避不了则须要靠多级缓存。若是热Key的话加Redis可能还不够，由于Redis也是单点的，可能还须要考虑本地多级缓存。或者用redis自己的这种前端proxy作负载均衡才能解决问题。热Key这种问题是比较难处理的，我估计不少开发人员都会所面临这种问题。但你要避免热Key出如今Cassandra中，若是出现了，对Cassandra影响会比较大，甚至会影响正常Key的访问。所以热Key在设计阶段必定是要规避的。

运维实践经验分享：CQL发布

咱们有这么大的规模，所以咱们常常有一些变动，须要一些数据库的自动化平台来帮咱们提高一些效率并下降一些风险。咱们的DBA人数有限，可能不能完成这么多事情。

咱们如今有一个CQL的审核模块，它会自动把你的那些你看到那些DDL脚本解析出来。若是是非高危字段，咱们可让你走自动化变动流程。若是是DROP这样高危的删除字段操做，咱们是不会让你自动在现网上运行的，要走另外的流程。对于那些刚开始的，尤为是有些公司没有运维的同事，大家的变动里若是有高危操做你必定要先识别出来。还要考虑操做前有没有备份，出现极端状况下是否有可挽救的措施，这些是必定要注意的。

运维实践经验分享：基于AIOPS多维度故障诊断

最后咱们介绍下监控，由于前面看到线上的一些朋友在问监控怎么作，咱们也分享一下咱们的经验。其实咱们比较简单，就像一些技术指标监控，这种你们都会。不少开源软件都很方便，网上的文档也不少，像早期的Zabbix和如今的Prometheus。包括Cassandra内部的JMX，在采集metrics时都有现成的模版，Prometheus也都有相关的支持。我以为你们能够把这些监控都加上。咱们后面也有本身加的监控，好比说咱们本身在驱动里面会把一些时延成功率等这些信息打到日志里，而后上报到咱们的日志平台中作一些监控。

这个好处是你能够端到端去看你Cassandra的状况，观察客户端到Cassandra的时延成功率是怎样的。这有利于你经过一些网络等帮助你去对问题进行一些定位。还有好比咱们时延成功率，咱们能够作一些动态预知的告警，咱们平台有机器学习的能力，当你忽然有波动的时，好比有业务版本变动或者业务忽然有个浪涌上来了，这时候你就知道有异常。这种便有利于提早及时去发现问题。

运维实践经验分享：自动化巡检

咱们还讲一下巡检，巡检其实跟监控有一点差别。巡检实际上是提早去发现问题，不是等告警的时候才发现问题。咱们针对前面讲的一些指标容量风险，包括成功率时延等等进行一些巡检，但咱们会作一些图。

其实对一些没有专门运维人员的小公司，你能够用那些监控的API接口本身写一个python脚本或一个Java程序。脚本天天把数据采集出来，统计汇总后，发邮件给相关责任人看一下，这样也是蛮好的，也不须要作这么漂亮的一个图。

社区版Cassandra的运维优化建议

前面咱们讲了运维面临的一些挑战和实践经验，其实咱们也遇到了一些问题，想提出来和你们探讨一下。

但愿改进的功能：

• Repair： 由于repair仍是比较消耗CPU和IO资源的，在集群数量大时，修复时间会变长，咱们还要关注对业务有没有额外影响。但愿后期有人能对repair的资源占用作出必定的限制，好比作一些限制配置类的东西。

• 数据迁移的方案： 还有就是数据迁移的方案，好比之后业务要从其它数据库或者IDC机房迁移到云上的话，Cassandra有没有一些好的迁移方案，这样开发者就不须要本身作一些开发，从而提升应用性。

• 数据一致性不可度量和监控：对于数据一致性不可度量，我以为一时半会也没有什么好的解决方案，没办法很好的监控。

• 二级索引： 目前已经支持的两种二级索引其实都是不太推荐你们使用的。

但愿支持的功能：

• 支持表计数统计：咱们有不少开发人员带着SQL的使用思路，想查询一张表有多少条记录。其实这目前是查不出来的，咱们只能经过其它手段进行一些统计。

• Nodetool支持commitlog的解析和回放：目前社区尚未这个功能，若是作到的话，数据备份就能够作到按时间点恢复，也就是真正的PITR(Point-In-Time-Recovery)。

• 墓碑：还有就是墓碑的一些优化。

待探讨:

• RocksDB（优化GC问题）：前面不少老师也提到了，RocksDB应该也是有一些规划的。目前RocksDB也比较火爆，不少大厂如今都在考虑用RocksDB作一些多模数据库。存储引擎好像都会用会考虑用Rocksdb。

• 3AZ部署状况下驱动优化路由算法，也就是下降跨AZ访问的时延。

• 将来是否会考虑分支，将存算分离、强一致性做为一个分支。咱们企业云的兄弟部门在这方面作了一些尝试。

最后，咱们2020年经历了全球的疫情，这对线上的应用确实是爆发式的增加。对于Cassandra来讲是有不少机会的，实际上咱们华为终端有不少应用是能够用Cassandra的。好比一些原来用Redis的能够切换到Cassandra，这对Cassandra来讲都是一些机会。

提问环节

问： 怎样实现C*数据冗余复制和控制存储成本之间的平衡？

答：其实这是一个可靠性和成本之间的取舍。得根据业务场景来看，咱们有一些业务它数据是核心数据，那它也愿意多出一些成本。好比说它的副本能够为三甚至达到AZ级容灾。同城双活的话，那就是6个副本。

 

若是对于数据可靠性要求不是特别高，三副本其实能够解决大部分的问题。甚至有一些用OLAP的场景有的咱们有离线的数据，用两个副本也是ok的，要根据业务的实际场景来。

问：大集群中数据一致性修复的挑战有哪些？

答：这个问题我以为提的很好，咱们原来一些大集群，在面对前面的大数据修复时，它要面临几个问题。第一个它的修复周期特别长，还有一个就是咱们对现网的影响。你修复时要控制住，不能让它有对现网产生影响。须要控制修复的并发，包括token段的切分，要切的足够小。

 

问：自动化C*集群运维的挑战在哪里？有哪些技术和工具能够参考？

答：其实运维这一块，咱们前面其实也提到了，以前介绍了一些咱们主要遇到的问题。自动化运维的话，咱们有作一些自动发布和自动部署，这能够提高一些效率。也包括监控这一块，咱们讲了一些多维度的监控，还有巡检。

 

监控的工具方面，一开始咱们有用OpsCenter，开源的像是Zabbix和Prometheus这些。用于定位问题的像是自带的nodetool，有不少命令，对于平常运维效率是颇有帮助的，我建议你们都去了解一下。