高并发大容量NoSQL解决方案探索

  • 时间:
  • 浏览:1

个推Redis监控繁杂性

据官方统计,截止目前(2018年4月20日)NoSQL有22好多少 出理 方案,具体到每个公司,使用的都在其中很小的一另另有有好多少 子集,下图中淡蓝色标注的产品是当前个推正在使用的。

欢迎工作一到五年的Java工程师亲戚大伙们加入Java架构开发:744677563

个推Codis+的优势

第一另另有有好多少 案例是一次主从重置。你這個 清况 是在春节前四天老要出現的,春节前属于消息推送业务高峰期。亲戚亲戚大伙简单还原一下故障场景。首先是大规模的消息采集是因为负载增加;否则,Redis Master压力增大,TCP包积压,OS产生丢包大间题,丢包把Redis主从ping的包给丢了,触发了repl-timeout 30秒的阈值,主从就重置了。一块儿否则节点过大,是因为Swap和IO饱和度接近30%。出理 的土办法很简单,亲戚亲戚大伙先把主从断开。故障是因为首先是参数不合理,大都在默认值,其次是节点过大让故障效果进行放大。

否则在使用过程中,亲戚亲戚大伙也发现许多局限。否则亲戚亲戚大伙提出了Codis+,即对Codis做许多功能增强。

关于亲戚亲戚大伙遇到的坑,接下来分享多少实际的案例。

一、配置CPU亲和。Redis是单机点的特征,不亲和会影响CPU的波特率。

第好多少 案例是codis最近遇到的一另另有有好多少 大间题。这是一另另有有好多少 典型的故障场景。一台主机挂掉后,codis开启了主从切换,主从切换后业务没办法 受影响,否则亲戚亲戚大伙去重新接主从时发现接不上,接不上就报了错。你這個 错倘若难查,随便说说倘若参数设置过小,也是否则默认值是因为。Slave从主节点拉数据的过程中,新增数据留在Master缓冲区,否则Slave还没拉完,Master缓冲区就超过上限,就会是因为主从重置,进入一另另有有好多少 死循环。

实现分布式主要有三种手段:副本(Replication)和分片(Sharding)。Replication能出理 读的扩展性大间题和HA(高可用),否则无法出理 读和容量的扩展性。而Sharding可以 出理 读写和容量的扩展性。一般NoSQL出理 方案都在将二者组合起来。

首先是技术架构演进过程。个推以面向APP开发者提供消息推送服务起家,在2012年另一另另有好多少 ,个推的业务量相对较小,当时亲戚亲戚大伙用Redis做缓存,用MySQL做持久化。在2012-2016年,随着个推业务的高速发展,单节点否则无法出理 大间题。在MySQL无法出理 高QPS、TPS的清况 下,亲戚亲戚大伙自研了Redis分片方案。此外,亲戚亲戚大伙还自研了Redis客户端,用它来实现基本的集群功能,支持自定义读写比例,一块儿对故障节点的监测和隔离、慢监控以及每个节点健康性进行检查。但你這個 架构没办法 不多考虑运维波特率的大间题,缺少运维工具。

Redis的主从重置一般是触发了如下条件中的一另另有有好多少 。

三类监控对象:集群、实例、主机,前要有元数据维护逻辑关系,并在全局做聚合。

此外,关于Redis,亲戚亲戚大伙最近还在看一另另有有好多少 新的NoSQL方案Aerospike,亲戚亲戚大伙对它的定位是替换次要集群Redis。Redis的大间题在于数据常驻内存,成本很高。亲戚亲戚大伙期望利用Aerospike减少TCO成本。Aerospike有如下特征:

下面讲一下搭建过程中遇到的多少坑。

个推Redis系统规模如下图。下面介绍一下运维过程遇到的多少大间题。

三种集群架构:自研、codis2和codis3,你這個 种架构采集数据的土办法不须相同。

NoSQL的由来

采集线程是亲戚亲戚大伙自行研发的,针对公司的业务特点定制化程度很高。还有ELK(不用logstach,用filebeat)做日志中心。

扩容和缩容

5、其它。比如有没办法 成功案例,有没办法 完善的文档和社区,有没办法 官方否则企业支持。可以 让别人把坑踩过另一另另有好多少 亲戚亲戚大伙平滑过去,毕竟被委托人踩坑的成本还是蛮高的。

三、主机剩余内存最好大于最大节点大小+10G。主从重置前要有同等大小的内存,你這個 一定要留够,否则不留够,用了Swap,就比较慢重置成功。

不懂得大间题都可以 在本群提出来 另一另另有好多少 都在有职业生涯规划以及面试指导

4、运维成本和可不可监控,可以 方便地进行扩容、缩容。

3、数据规模。数据规模越大,前要考虑的大间题就不多,选者性就越小。到了几百个TB否则PB级别,几乎没不多选者,倘若Hadoop体系。

Zabbix是一另另有有好多少 非常完备的监控系统,约三年多的时间里,我都把它作为主要的监控系统平台。否则它有一另另有有好多少 匮乏:一是它使用MySQL作为后端存储,TPS有上限;二是匮乏灵活。比如:一另另有有好多少 集群插进一百台机器上,要做聚合指标,就很困难。

1、业务逻辑。首比较慢了解自身业务特点,比如是KV型就在KV顶端找;否则是图型就在图型里找,另一另另有好多少 范围一下会减少70%-30%。

grafana监控系统聚合了多个IDC数据,亲戚亲戚大伙运维每天只需看一下大屏就够了。

个推常用的几种NoSQL出理 方案

三、支持机架感知和跨IDC的同步,但这属于企业级版本功能。

第好多少 是CMDB,你這個 是维护主机上的软件信息,主机上装了哪些实例,实例属于哪些集群,亲戚亲戚大伙用了哪些端口,哪些集群哪些个性化的参数配置,包括告警机制不一样,都在通过CMDB实现。CMDB的数据消费方所含grafana监控系统和监控采集线程,采集线程由亲戚亲戚大伙被委托人开发。另一另另有好多少 CMDB数据会活起来。否则倘若一另另有有好多少 静态数据没办法 消费方,数据就会不一致。

NoSQL与RDMBS的区别主要在两点:第一,它提供了无模式的灵活性,支持很灵活的模式变更;第二,可伸缩性,原生的RDBMS只适用于单机和小集群。而NoSQL一现在开始了了英语 倘若分布式的,出理 了读写和容量扩展性大间题。以上两点,也是NoSQL产生的根本是因为。

六、Master不做持久化,Slave做AOF+定时重置。

以上都在是因为主从重置的是因为,主从重置的后果很严重。Master压力爆增无法提供服务,业务就把你這個 节点定为不可用。响应时间变长 Master所在所有主机的节点都在受到影响。

二、资源池化,运维成本继续降低。

第二、Redis准半同步。设置一另另有有好多少 阈值,比如slave仅在5秒钟之内可读。

基于哪些案例,亲戚亲戚大伙采集了一份最佳实践。

通过以上哪些,亲戚亲戚大伙搭建出个推整个监控体系。

亲戚亲戚大伙共分了一另另有有好多少 次要:OS标准化、Redis文件和目录标准、Redis参数标准化,详细用saltstack + cmdb实现;

大次要的运维同学都应该认真阅读《SRE:Google运维揭秘》,它在理论层面和实践层面提出了全都非常有价值的土办法论,强烈推荐。

本群提供免费的学习指导 架构资料 以及免费的解答

此外,还有机架感知功能和跨IDC的功能。Redis三种是为了单机房而设置的,没办法 考虑到哪些大间题。

第一、 采用2N+1副本方案,出理 故障期间Master单点的大间题。

结语:关于NoSQL的释义,网络上曾一另另有有好多少 多段子:从1930年的know SQL,到305年的Not only SQL,再到今日的No SQL!互联网的发展伴随着技术概念的更新与相关功能的完善。而技术进步的面前,则是每一位技术人的持续的学习、周密的思考与不懈的尝试。

1946年,第一台通用计算机诞生。但老要到1970年RDMBS的老要出現,亲戚亲戚大伙才找到通用的数据存储方案。到21世纪,DT时代让数据容量成为最棘手的大间题,对此谷歌和亚马逊分别提出了被委托人的NoSQL出理 方案,比如谷歌于306年提出了Bigtable。309年的一次技术大会上,NoSQL一词被正式提出,到现在共有225种出理 方案。

1、repl-backlog-size太小,默认是1M,否则你有极少量的写入,很容易击穿你這個 缓冲区;2、repl-timeout,Redis主从默认每十秒钟ping一次,30秒钟ping不推就会主从重置,是因为否则是网络抖动、总节点压力过大,无法响应你這個 包等;3、tcp-baklog,默认是511。操作系统的默认是限制到128,你這個 可以 适度提高,亲戚亲戚大伙提高到2048,你這個 能对网络丢包大间题进行一定容错。

五、tcp-backlog、repl-backlog-size、repl-timeout适度增大。

Codis是proxy-based架构,支持原生客户端,支持基于web的集群操作和监控,否则也集成了Redis Sentinel。可以 提高亲戚亲戚大伙运维的工作波特率,且HA也更容易落地。

Sharding主要出理 数据的划分大间题,主要有基于区间划分(如Hbase的Rowkey划分)和基于哈希的划分。为了出理 哈希分布式的单调性和平衡性大间题,目前业内主要使用虚拟节点。后文所述的Codis也是用虚拟节点。虚拟节点合适 在数据分片和托管服务器之间建立了一层虚拟映射的关系。

一、主从重置,会是因为主机节点压力爆增,主节点无法提供服务。

目前,亲戚亲戚大伙主要根据数据模型和访问土办法进行NoSQL分类。

最后是被委托人的许多思考和建议。选者适合被委托人的NoSQL,选者原则有五点:

下图是个推运维平台。

四、尽量不须用Swap。30毫秒响应一另另有有好多少 请求还不如挂掉。

2、负载特点,QPS、TPS和响应时间。在选者NoSQL方案时,可以 从哪些指标去衡量,单机在一定配置下的性能指标能达到多少?Redis在主机足够剩余清况 下,单台的QPS40-30万是详细OK的。

没办法 ,为哪些亲戚亲戚大伙不用原生的rRedis cluster?这里有一另另有有好多少 是因为:一、原生的集群,它把路由转发的功能和实际上的数据管理功能耦合在一另另有有好多少 功能里,否则一另另有有好多少 功能出大间题就会是因为数据有大间题;二、在大集群时,P2P的架构达到一致性清况 的过程比较耗时,codis是树型架构,不指在你這個 大间题。三、集群没办法 经过大平台的背书。

大数据时代,企业对于DBA也提出更高的需求。一块儿,NoSQL作为近几年新崛起的一门技术,也受到不多的关注。本文将基于个推SRA孟显耀先生所负责的DBA工作,和大数据运维相关经验,分享两大方向内容:一、公司在KV存储上的架构演进以及运维前要出理 的大间题;二、对NoSQL咋样选型以及未来发展的许多思考。

当亲戚亲戚大伙计划完善运维工具的另一另另有好多少 ,发现豌豆荚团队将Codis开源,给亲戚亲戚大伙提供了一另另有有好多少 不错的选项。

在NoSQL演进的过程中,亲戚亲戚大伙也遇到许多运维方面的大间题。

第三、资源池化。能通过类事HBase增加RegionServer的土办法去进行资源扩容。

做好监控,降低运维成本

二、节点过大,次也不人为是因为造成的。第一是拆分节点的波特率较低,远远慢于公司业务量的增长。此外,分片不多。亲戚亲戚大伙的分片是30个,codis是1024,codis原生是1638一另另有有好多少 ,分片不多也是个大间题。否则做自研的分布式方案,亲戚亲戚大伙一定要把分片数量,稍微设大许多,出理 业务发展超过你预期的清况 。节点过大另一另另有好多少 ,会是因为持久化的时间增长。亲戚亲戚大伙30G的节点要持久化,主机剩余内存要大于30G,否则没办法 ,你用Swap是因为主机持久化时间大幅增长。一另另有有好多少 30G的节点持久化否则要一另另有有好多少 小时。负载匮乏也会是因为主从重置,引起连锁反应。

主从重置有全都是因为。

亲戚亲戚大伙现在主要使用的是2.8.20,属于比较容易能产生主从重置。

Redis版本低,主从重置的概率很高。Redis3主从重置的概率比Redis2大大减少,Redis4支持节点重启另一另另有好多少 可以 增量同步,这是Redis三种进行了全都改进。

二、节点大小控制在10G。

小米的open-falcon出理 了你這個 大间题,否则也会产生许多新大间题。比如告警函数很少,不支持字符串,有另一另另有好多少 会增加手工的操作等等。已经 亲戚亲戚大伙对它进行功能性补充,便没办法 遇到大的大间题。

一、Aerospike数据可以 放内存,也可以 放SSD,并对SSD做了优化。

第一另另有有好多少 是IT硬件资源平台,主要维护主机维度的物理信息。比如说主机在哪个机架上接的哪个交换机,在哪个机房的哪一另另有有好多少 楼层等等,这是做机架感知和跨IDC等等的基础。

目前亲戚亲戚大伙内内外部现在有一另另有有好多少 业务在使用Aerospike,实测下来,发现单台物理机搭载单块Inter SSD 4300,可以 达到接近10w的QPS。对于容量较大,但QPS要求不高的业务,可以 选者Aerospike方案节省TCO。

标准化安装

Slatstack,用于实现自动化发布,实现标准化并提高工作波特率。

三种个性化配置:个推的Redis集群,有的集群前要有多副本,有的不前要。有的节点允许满做缓存,有的节点不允许满。还有持久化策略,有的不做持久化,有的做持久化,有的做持久化+异地备份,哪些业务特点对亲戚亲戚大伙监控灵活性提出很高的要求。

在技术架构不断演进过程中,扩容和缩容的难度也在变低,是因为之一在于codis缓解了一次要大间题。当然,否则选者Aerospike,相关操作就会非常轻松。