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

实现分布式主要有两种手段：副本（Replication）和分片（Sharding）。Replication能解决读的扩展性问题和HA（高可用），但是无法解决读和容量的扩展性。而Sharding可以解决读写和容量的扩展性。一般NoSQL解决方案都是将二者组合起来。

Sharding主要解决数据的划分问题，主要有基于区间划分（如Hbase的Rowkey划分）和基于哈希的划分。为了解决哈希分布式的单调性和平衡性问题，目前业内主要使用虚拟节点。后文所述的Codis也是用虚拟节点。虚拟节点相当于在数据分片和托管服务器之间建立了一层虚拟映射的关系。

个推Codis+，Codis+，即对Codis做一些功能增强。

第一、 采用2N+1副本方案，解决故障期间Master单点的问题。

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

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

个推新的NoSQL方案Aerospike，我们对它的定位是替换部分集群Redis。Redis的问题在于数据常驻内存，成本很高。我们期望利用Aerospike减少TCO成本。Aerospike有如下特性：

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

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

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

目前我们内部现在有两个业务在使用Aerospike，实测下来，发现单台物理机搭载单块Inter SSD 4600，可以达到接近10w的QPS。对于容量较大，但QPS要求不高的业务，可以选择Aerospike方案节省TCO。做自研的分布式方案，大家一定要把分片数量，稍微设大一点，避免业务发展超过你预期的情况。节点过大之后，会导致持久化的时间增长。

最后是个人的一些思考和建议。选择适合自己的NoSQL，选择原则有五点：

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

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

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

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

5、其它。比如有没有成功案例，有没有完善的文档和社区，有没有官方或者企业支持。可以让别人把坑踩过之后我们平滑过去，毕竟自己踩坑的成本还是蛮高的

参考：http://baijiahao.baidu.com/s?id=1600677387636622909&wfr=spider&for=pc

转载请注明：比度技术-关注互联网技术的个人博客 » 高并发大容量NoSQL解决方案探索