• 公司概况
  • 产品中心
  • 工程案例
  • 新闻中心
  • 人力资源
  • 产品手册
  • 在线订单
  • 联系我们
  • 您当前的位置:首页 > 工程案例

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

    时间:2018-12-06 08:29:21  来源:本站  作者:

      首先是技术架构演进过程。个推以面向APP开发者提供消息推送服务起家,在2012年之前,个推的业务量相对较小,当时用Redis做缓存,用MySQL做持久化。在2012-2016年,随着个推业务的高速发展,单节点已经无法解决问题。在MySQL无法解决高QPS、TPS的情况下,自研了Redis分片方案。此外,还自研了Redis客户端,用它来实现基本的集群功能,支持自定义读写比例,同时对故障节点的监测和隔离、慢监控以及每个节点健康性进行检查。但这种架构没有过多考虑运维效率的问题,缺少运维工具。

      Codis是proxy-based架构,支持原生客户端,支持基于web的集群操作和监控,并且也集成了RedisSentinel。可以提高我们运维的工作效率,且HA也更容易落地。

      但是在使用过程中,也发现一些局限。因此提出了Codis+,即对Codis做一些功能增强。

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

      第三、资源池化。能通过类似HBase增加RegionServer的方式去进行资源扩容。

      此外,还有机架感知功能和跨IDC的功能。Redis本身是为了单机房而设置的,没有考虑到这些问题。

      那么,为什么我们不用原生的rRediscluster?这里有三个原因:一、原生的集群,它把路由转发的功能和实际上的数据管理功能耦合在一个功能里,如果一个功能出问题就会导致数据有问题;二、在大集群时,P2P的架构达到一致性状态的过程比较耗时,codis是树型架构,不存在这个问题。三、集群没有经过大平台的背书。

      此外,关于Redis,我们最近还在看一个新的NoSQL方案Aerospike,我们对它的定位是替换部分集群Redis。Redis的问题在于数据常驻内存,成本很高。我们期望利用Aerospike减少TCO成本。Aerospike有如下特性:

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

      目前内部现在有两个业务在使用Aerospike,实测下来,发现单台物理机搭载单块InterSSD4600,可以达到接近10w的QPS。对于容量较大,但QPS要求不高的业务,可以选择Aerospike方案节省TCO。

      第一个案例是一次主从重置。首先是大规模的消息下发导致负载增加;然后,RedisMaster压力增大,TCP包积压,OS产生丢包现象,丢包把Redis主从ping的包给丢了,触发了repl-timeout60秒的阈值,主从就重置了。同时由于节点过大,导致Swap和IO饱和度接近100%。解决的方法很简单,我们先把主从断开。故障原因首先是参数不合理,大都是默认值,其次是节点过大让故障效果进行放大。

      第二个案例是codis最近遇到的一个问题。这是一个典型的故障场景。一台主机挂掉后,codis开启了主从切换,主从切换后业务没有受影响,但是我们去重新接主从时发现接不上,接不上就报了错。这个错也不难查,其实就是参数设置过小,也是由于默认值导致。Slave从主节点拉数据的过程中,新增数据留在Master缓冲区,如果Slave还没拉完,Master缓冲区就超过上限,就会导致主从重置,进入一个死循环。

      一、配置CPU亲和。Redis是单机点的结构,不亲和会影响CPU的效率。

      三、主机剩余内存最好大于最大节点大小+10G。主从重置需要有同等大小的内存,这个一定要留够,如果不留够,用了Swap,就很难重置成功。

      1、业务逻辑。首先要了解自身业务特点,比如是KV型就在KV里面找;如果是图型就在图型里找,这样范围一下会减少70%-80%。

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

      3、数据规模。数据规模越大,需要考虑的问题就越多,选择性就越小。到了几百个TB或者PB级别,几乎没太多选择,就是Hadoop体系。

      5、其它。比如有没有成功案例,有没有完善的文档和社区,有没有官方或者企业支持。

    来顶一下
    推荐资讯
    相关文章
      无相关信息
    栏目更新
    栏目热门