后使用快捷导航没有帐号？
查看: 5676|回复: 30
内存分布式中间件，你看好哪个？并说说你的理由
论坛徽章:763
内存分布式中间件，你看好哪个？并说说你的理由（字数不少于50字）
1、本周互动作业请在当前主题帖内进行发布，其他版块发起回复贴无效。
2、回复内容需符合主题帖讨论方向，灌水或者复制他人回帖，管理员及老师可以删除此贴，并判处作业不合格。
3、发起回帖需符合：1个回帖，字数不少50个字符的帖子。
注册会员, 积分 115, 距离下一级还需 85 积分
论坛徽章:2
根据业务场景选择合适的内存分布式中间件，并没有对哪个有特别的偏好。
从以下几个维度，对redis、memcache、mongoDB 做对比：
都比较高，性能对我们来说应该都不是瓶颈。总体来讲，TPS方面redis和memcache差不多，要大于mongodb。
2、操作的便利性
memcache数据结构单一；
redis丰富一些，数据操作方面，redis更好一些，较少的网络IO次数；
mongodb支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言非常丰富。
3、内存空间的大小和数据量的大小
redis在2.0版本后增加了自己的VM特性，突破物理内存的限制；可以对key value设置过期时间（类似memcache）；
memcache可以修改最大可用内存,采用LRU算法；
mongoDB适合大数据量的存储，依赖操作系统VM做内存管理，吃内存也比较厉害，服务不要和别的服务在一起。
4、可用性（单点问题）
对于单点问题，redis，依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整个快照,无增量复制，因性能和效率问题，所以单点问题比较复杂；不支持自动sharding,需要依赖程序设定一致hash 机制。一种替代方案是，不用redis本身的复制机制，采用自己做主动复制（多份存储），或者改成增量复制的方式（需要自己实现），一致性问题和性能的权衡；Memcache本身没有数据冗余机制，也没必要；对于故障预防，采用依赖成熟的hash或者环状的算法，解决单点故障引起的抖动问题；mongoDB支持master-slave,replicaset（内部采用paxos选举算法，自动故障恢复）,auto sharding机制，对客户端屏蔽了故障转移和切分机制。
5、可靠性（持久化）
对于数据持久化和数据恢复，redis支持（快照、AOF）：依赖快照进行持久化，aof增强了可靠性的同时，对性能有所影响；memcache不支持，通常用在做缓存,提升性能；MongoDB从1.8版本开始采用binlog方式支持持久化的可靠性。
6、数据一致性（事务支持）
Memcache 在并发场景下，用cas保证一致性；redis事务支持比较弱，只能保证事务中的每个操作连续执行；mongoDB不支持事务。
7、数据分析
mongoDB内置了数据分析的功能(mapreduce),其他不支持。
8、应用场景
redis：数据量较小的更性能操作和运算上；memcache：用于在动态系统中减少数据库负载，提升性能;做缓存，提高性能（适合读多写少，对于数据量比较大，可以采用sharding）；MongoDB:主要解决海量数据的访问效率问题。
注册会员, 积分 66, 距离下一级还需 134 积分
论坛徽章:9
我以一个实际的案例来说吧，因为我们的背景是给JAVA EE应用服务器的session做集群，因此要求按照下面的几点进行预研1.License以上7个开源软件基本都是基于apache或者BSD这样商业友好的license，但是个别的可能有企业版，例如Membase；或者其监控管理工具需要企业版license，例如HazelCast；因此需要首先弄清license的状况；//具体license的作用可以不用细研究，目前来说，我们可以接受的license类型只有Apache,MIT和BSD这3个。 2.单点问题的支持情况及解决方案以上7个除了Memcached，其他基本都可以在服务端原生支持单点失效问题，预研时需要研究各个NoSQL对单点问题的解决方案是什么样的，例如组间复制、写入磁盘等等；PS: 需要对各方案的优缺点做下对比 3.对失败转移和故障恢复的支持情况3.1当前读写操作失败后，是否有失败转移策略；3.2 NoSQL节点由故障状态恢复正常后是否可以继续接收请求； 4.客户端支持情况以上很多都支持Memcached协议，可以直接使用Java版的memcached客户端，这样客户端可以复用twns的代码；如果不支持Memcached协议，需要研究下客户端调用方式和配置方式； 5.性能先构造统一的用例，然后对各个NoSQL进行性能测试；性能测试重点关注2个角度:5.1 单点的读写性能;5.2 集群下(NoSQL实例数大于等于2)的读写性能；Ps: 每个角度又可细分为大数据包和小数据包两种场景 6.可扩展性需要研究各NoSQL对动态扩展的支持情况(运行时实时扩展NoSQL集群节点)，扩展类型是支持复制现有数据还是只能做容量上的水平扩展； 7.读写限制7.1 是否原生支持非序列化对象； //不支持的可以采用第3方序列化工具，例如kryo，javolution等；7.2 是否对每次读写对象的大小有限制；(例如Redis的单个value限制是1G) 8.监控管理工具是否自带监控管理工具，如果带，是否有使用上的限制(license或别的什么因素)，提供哪些具体功能；如果不带，那么是否提供接口可以做监控管理，接口类型和调用方式； 9.稳定性通过相对长一点时间的压力测试(单个value的大小可以大一点)，测试其读写稳定性，是否存在内存泄漏等问题； 10.其他特点例如NoSQL容量已满后支持何种处理策略，像LRU,LFU等等；
经过对比测试：一.功能对比Vordemort,couchbase,hazelcast的对比见附件：各缓存综合对比.xlsx的表格(内容同邮件下面的表格)，第一列加黑体的是比较重要的功能项，表格里绿色表示支持良好，黄色表示支持一般，红色表示支持较差或存在明显缺陷,灰色表示暂不关注。 就功能来说综合表现最好的是Hazelcast. 其次是couchbase，而voldemort存在较多缺陷。Couchbase在failover和rebalance上存在的使用限制较为不便，需要人为手动参与； PS: Redis,Cassandra,ehcache这次没有做客户端的各种容错性测试以及性能测试，所以不参加选型对比。 二.性能对比 1.三者中couchbase性能最好(voldemort和hazelcast基本是同一水平)，特别是写性能和大数据包的读写性能(更详细的测试结果见附件的：各缓存性能测试数据对比.xlsx)，都具有压倒性优势，但是couchbase在存1k字节数组时存在一个比较严重的bug，数据量超过4W就会发生数据丢失，这个问题不解决是没办法用于生产环境的。 2.小数据包(1k)的读性能，三者基本是同一水平； 3.缓存节点在集群模式下，couchbase的tps和单节点比几乎没有下降，而基于java语言的voldemort和hazelcast在集群模式下都发生了明显的读写性能下降(4节点集群下降约50%)； 在性能方面：couchbase具有绝对的优势，但是比较可惜的是在1k字节数组的写入上存在严重bug，现在没办法采用(现阶段我们没有时间去解决couchbase的bug)；虽然voldemort和hazelcast的写入性能没有那么好，但是在session复制时，写入操作可以是异步执行的，所以写入慢基本不会影响请求响应时间，而读取操作是同步的，会影响请求响应时间，从表格上可以看到在小数据包的读取上三者差别不大，因此voldemort和hazelcast在性能上也是可以接受的(session中存的通常都是状态信息或简单数据，而不建议存大的复杂对象，所以session对象序列化后的体积通常不会很大，如果有大体积的session对象，可以用压缩来缓解) 三.综合对比
从功能和性能两方面综合对比后，hazelcast是本次对比胜出的，功能上是最完整的，性能也可以接受，但是从性能测试结果可以看出使用hazelcast会有一些“使用建议”：session不宜存大对象，hazelcast集群节点的数目会影响存取效率(具体是否是随着节点数增加线性下降还需要测试进一步验证)。
VoldemortcouchbaseHazelcast1.Licenseapacheapacheapache2.单点问题的支持情况及解决方案支持。
保存多份，持久化硬盘。支持。
复制多份副本。支持。组内复制，持久化数据库。3.对失败转移和故障恢复的支持情况3.1当前读写操作失败后，是否有失败转移策略；不支持失败转移。支持。但自动failover有限制,3节点以下需要手动。支持3.2 NoSQL节点由故障状态恢复正常后是否可以继续接收请求；支持。但不会自动rebalance支持。
但需要手动rebalance支持。自动rebalance4.客户端支持情况不支持memcached协议，有自己的客户端。smart client。兼容memcached客户端1. 本地客户端
2. Memcache客户端
3. REST客户端。4.5 客户端容错性教差(客户端初始化节点挂掉，分配到该节点的写操作都会失败)较好 (客户端初始化节点挂掉仍可继续使用)较好 (客户端初始化节点挂掉仍可继续使用)5.性能(客户端4线程90%读10%写的TPS)单点value=1K89059821(超过4W丢失数据)10307value=1M8047287value=4M1311525集群(4缓存节点)value=1K592572825988value=1M4245224value=4M710496.可扩展性可以动态扩展。
但手动rebalance没有复制数据。可以动态扩展。可以动态扩展7.读写限制7.1 是否原生支持非序列化对象； 支持插入第3方序列化框架原生是不支持非序列化对象的。内置序列化机制，可扩展。　7.2 是否对每次读写对象的大小有限制；受堆内存影响。Memory方式比bdb方式利用率高一些测试可以支持300M受堆内存影响。8.监控管理工具没有自带监控管理工具，也没有专门的接口。提供JMX监控管理，但可用操作较少有功能完善的图形化监控工具，社区版和企业版在功能上没有差别。 提供rest api有图形化监控工具，但有license限制。 提供JMX监控
新手上路, 积分 29, 距离下一级还需 21 积分
论坛徽章:2
看好GemFire，毕竟经过了12306的高并发，大负载的考验。通过云计算平台虚拟化技术，将若干X86服务器的内存集中起来，组成最高可达数十TB的内存资源池，将全部数据加载到内存中，进行内存计算。计算过程本身不需要读写磁盘，只是定期将数据同步或异步方式写到磁盘。GemFire在分布式集群中保存了多份数据，任何一台机器故障，其它机器上还有备份数据，不用担心数据丢失，而且有磁盘数据作为备份。GemFire支持把内存数据持久化到各种传统的关系数据库、Hadoop库和其它文件系统中。12306之前采用Unix小型机架构，采用GemFire技术改造成Linux/X86服务器集群架构。
新手上路, 积分 23, 距离下一级还需 27 积分
论坛徽章:1
我们现在主要用了memcached和redis，针对一些不需要持久化的缓存用的是memcached，不过由于数据比较复杂，感觉用了memcached后，性能提升并不明显。针对需要持久化存储的，一般会使用redis，重启服务后，可以直接进行初始化，不像memcached一般在服务重启后，刚开始会频繁的写一一些数据过去。目前也在研究GemFire，不过我们现在的架构和访问量还都比较小，所以没有实际使用过。
中级会员, 积分 261, 距离下一级还需 239 积分
论坛徽章:4
Tachyon是一个分布式内存文件系统，可以在集群里以访问内存的速度来访问存在tachyon里的文件。把Tachyon是架构在最底层的分布式文件存储和上层的各种计算框架之间的一种中间件。主要职责是将那些不需要落地到DFS里的文件，落地到分布式内存文件系统中，来达到共享内存，从而提高效率。同时可以减少内存冗余，GC时间等。
金牌会员, 积分 2676, 距离下一级还需 324 积分
论坛徽章:37
还是要看不同的场景。 memcached虽然简单，也不可能被淘汰。Tachyon已经用在Spark中作为HDFS也Spark内存计算的中间层，已经在百度有大规模应用。redis在电商、新浪微博等系统中大量使用。Hazelcast也很有前途，但服务器的内存不够多的话，用Hazelcast意义不大。至于更看好谁，我觉得还是看使用场景吧。
新手上路, 积分 21, 距离下一级还需 29 积分
论坛徽章:1
Redis和memcached是日常总接触的，因此分一下几个角度对比分析：
1 网络IO模型
Memcached是多线程，非阻塞IO复用的网络模型，分为监听主线程和worker子线程，监听线程监听网络连接，接受请求后，将连接描述字pipe 传递给worker线程，进行读写IO, 网络层使用libevent封装的事件库，多线程模型可以发挥多核作用，但是引入了cache coherency和锁的问题，比如，Memcached最常用的stats 命令，实际Memcached所有操作都要对这个全局变量加锁，进行计数等工作，带来了性能损耗。
Redis使用单线程的IO多路复用模型，自己封装了一个简单的AeEvent事件处理框架，主要实现了epoll、kqueue和select，对于单纯只有IO操作来说，单线程可以将速度优势发挥到最大，但是Redis也提供了一些简单的计算功能，比如排序、聚合等，对于这些操作，单线程模型实际会严重影响整体吞吐量，CPU计算过程中，整个IO调度都是被阻塞住的。
2.内存管理方面
Memcached使用预分配的内存池的方式，使用slab和大小不同的chunk来管理内存，Item根据大小选择合适的chunk存储，内存池的方式可以省去申请/释放内存的开销，并且能减小内存碎片产生，但这种方式也会带来一定程度上的空间浪费。
Redis使用zmalloc进行内存分配，zmalloc下层使用tcmallc或者jemalloc。zmalloc 只是为每段分配内存额外增加一个8字节的头部，这个头部记录了此次分配的内存的长度。zmalloc等函数会自动处理偏移，用户无需知道头部的存在。zmalloc 定义了 used_memory 记录当前一共分配出去了多少内存。
3.数据一致性问题
Memcached提供了cas命令，可以保证多个并发访问操作同一份数据的一致性问题。
Redis没有提供cas 命令，并不能保证这点，不过Redis提供了事务的功能，可以保证一串命令的原子性，中间不会被任何操作打断。
4.存储方式及其它方面
Memcached基本只支持简单key-value存储，不支持枚举，不支持持久化和复制等功能。
Redis除key/value之外，还支持list,set,sorted set,hash等众多数据结构，提供了KEYS　　进行枚举操作，但不能在线上使用，如果需要枚举线上数据，Redis提供了工具可以直接扫描其dump文件，枚举出所有数据，Redis还同时提供了持久化和复制等功能。
注册会员, 积分 59, 距离下一级还需 141 积分
论坛徽章:1
本帖最后由 aaronfeng80 于
11:18 编辑
内存分布式中间件有Redis, Memecached，MongoDB，Hazelcast等，相对来说，我更看好Hazelcast，因为我觉得存储本身不应该是内存分布式重点需要解决的问题，反而应该是计算本才是重点。
新手上路, 积分 6, 距离下一级还需 44 积分
论坛徽章:2
分布式缓存中间件自己比较熟的有Redis, Memecached，阿里的Tair。另外通过这个课程也了解了Hazelcast、gridgain、SAP HANA、Gemfire。
使用什么中间件还是要看具体场景。比如Memecached就是用于数据库缓存,redis用于服务器缓存。
在一些百万用户系统随便找个缓存中间件搞搞是没问题的。但用户量上亿后，缓存中间件瓶颈就是存在于和自己系统业务相关的某个地方。这就需要自己去造轮子了，或者拿开源的根据自己的场景改。据我所知，互联网巨头也都是这么做的。【图文】3.1分布式系统-系统结构_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
3.1分布式系统-系统结构
上传于||暂无简介
大小：1.87MB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢