本文目录导航：
开源内存数据库有哪些
开源内存数据库包含：Redis、Memcached、H2、VoltDB等。
Redis是一种开源的内存数据库，它经常使用ANSI C言语编写，允许网络、可基于内存也可耐久化。
由于其高性能的数据读写才干，Redis宽泛运行于缓存系统、高并发场景的数据存取等。
它提供了多种数据结构类型，如字符串、列表、汇合、哈希等，还允许颁布/订阅、事务等初级配置。
2. Memcached
Memcached是一种散布式内存对象缓存系统，它可以用来缓存数据库查问结果或其余任何要求极速访问的数据。
Memcached基于内存的存储机制使其具有极高的性能，并且由于其开源的个性，获取了宽泛的运行。
它允许繁难的键值对存储，并且实用于要求高速缓存的场景。
H2是一个纯Java的内存数据库，它不只允许传统的相关型数据库配置，还提供了许多初级个性，如智能形式退化、智能备份等。
由于其齐全基于内存的个性，H2在要求极速访问少量数据的运行中体现优秀。
此外，H2还允许嵌入到Java运行程序中，繁难启动极速开发和测试。
VoltDB是一个开源的低提前内存数据库治理系统，专为要求高吞吐量和低提前的运行程序设计。
它允许ACID事务处置和数据的高并发访问，同时也具有智能数据分区和容错个性。
VoltDB既可作为独立的数据库经常使用，也可作为更大架构中的组件经常使用。
由于它的设计并重于实时处置少量数据和高并发操作，VoltDB十分适宜于各种大数据运行场景。
Memcached真的过时了吗？Redis与Memcached的比拟
这两年Redis火得可以，Redis也经常被当作Memcached的应战者被提到桌面过去。
关于Redis与Memcached的比拟更是亘古未有。
但是，Redis真的在配置、性能以及内存经常使用效率上都逾越了Memcached吗？上方内容来自Redis作者在stackoverflow上的一个回答，对应的疑问是《Is memcached a dinosaur in comparison to Redis?》（相比Redis，Memcached真的过时了吗？）You should not care too much about performances. Redis is faster per core with small values, but memcached is able to use multiple cores with a single executable and TCP port without help from the client. Also memcached is faster with big values in the order of 100k. Redis recently improved a lot about big values (unstable branch) but still memcached is faster in this use case. The point here is: nor one or the other will likely going to be your bottleneck for the query-per-second they can deliver.没有必要过多的关心性能，由于二者的性能都曾经足够高了。
由于Redis只经常使用单核，而Memcached可以经常使用多核，所以在比拟上，平均每一个核上Redis在存储小数据时比Memcached性能更高。
而在100k以上的数据中，Memcached性能要高于Redis，只管Redis最近也在存储大数据的性能上启动优化，但是比起Memcached，还是稍有逊色。
说了这么多，论断是，无论你经常使用哪一个，每秒处置恳求的次数都不会成为瓶颈。
（比如瓶颈或许会在网卡）You should care about memory usage. For simple key-value pairs memcached is more memory efficient. If you use Redis hashes, Redis is more memory efficient. Depends on the use case.假设要说内存经常使用效率，经常使用繁难的key-value存储的话，Memcached的内存应用率更高，而假设Redis驳回hash结构来做key-value存储，由于其组合式的紧缩，其内存应用率会高于Memcached。
当然，这和你的运行场景和数据个性无关。
You should care about persistence and replication, two features only available in Redis. Even if your goal is to build a cache it helps that after an upgrade or a reboot your>redis和memcached的区别
假设繁难地比拟Redis与Memcached的区别，大少数都会获取以下观念：1 Redis不只仅允许繁难的k/v类型的数据，同时还提供list，set，hash等数据结构的存储。
2 Redis允许数据的备份，即master-slave形式的数据备份。
3 Redis允许数据的耐久化，可以将内存中的数据坚持在磁盘中，重启的时刻可以再次加载启动经常使用。
在Redis中，并不是一切的数据都不时存储在内存中的。
这是和Memcached相比一个最大的区别（我团体是这么以为的）。
Redis只会缓存一切的key的消息，假设Redis发现内存的经常使用量超越了某一个阀值，将触发swap的操作，Redis依据“swappability = age*log(size_in_memory)”计算出哪些key对应的value要求swap到磁盘。
而后再将这些key对应的value耐久化到磁盘中，同时在内存中肃清。
这种个性使得Redis可以坚持超越其机器自身内存大小的数据。
当然，机器自身的内存必定要能够坚持一切的key，毕竟这些数据是不会启动swap操作的。
同时由于Redis将内存中的数据swap到磁盘中的时刻，提供服务的主线程和启动swap操作的子线程会共享这局部内存，所以假设更新要求swap的数据，Redis将阻塞这个操作，直到子线程成功swap操作后才可以启动修正。
可以参考经常使用Redis特有内存模型前后的状况对比：VM off: 300k keys, 4096 bytes values: 1.3G usedVM on: 300k keys, 4096 bytes values: 73M usedVM off: 1 million keys, 256 bytes values: 430.12M usedVM on: 1 million keys, 256 bytes values: 160.09M usedVM on: 1 million keys, values as large as you want, still: 160.09M used 当从Redis中读取数据的时刻，假设读取的key对应的value不在内存中，那么Redis就要求从swap文件中加载相应数据，而后再前往给恳求方。
这里就存在一个I/O线程池的疑问。
在自动的状况下，Redis会产生阻塞，即成功一切的swap文件加载后才会相应。
这种战略在客户端的数量较小，启动批量操作的时刻比拟适宜。
但是假设将Redis运行在一个大型的网站运行程序中，这显然是不可满足大并发的状况的。
所以Redis运转咱们设置I/O线程池的大小，对要求从swap文件中加载相应数据的读取恳求启动并发操作，缩小阻塞的期间。
redis、memcache、mongoDB 对比从以下几个维度，对redis、memcache、mongoDB 做了对比，欢迎拍砖1、性能都比拟高，性能对咱们来说应该都不是瓶颈总体来讲，TPS方面redis和memcache差不多，要大于mongodb2、操作的便利性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:重要处置海量数据的访问效率疑问
