分布式的实时文件存储，每个字段都被索引并可被搜索，分布式的实时分析搜索引擎
可以扩展到上百台服务器，处理PB级结构化或非结构化数据
2.Elasticsearch应用场景
分布式的搜索引擎和数据分析引擎，全文检索，结构化检索，数据分析
对海量数据进行近实时的处理，站内搜索（电商，招聘，门户，等等），IT系统搜索（OA，CRM，ERP，等等），数据分析
3.Elasticsearch的优缺点
缺点：没有用户验证和权限控制，没有事务的概念，不支持回滚，误删不能恢复，需要java环境.
优点：将你的文档分割到不同容器或者分片中，可以存在单个节点或多个节点
复制每个分片提供数据备份，防止硬件问题导致数据丢失。
对集群中任意节点的相互请求进行路由，保证获取的数据是你需要的，集群增加或者重新分配分片时，不停机让新节点恢复丢失的节点分片数据
4.Elasticsearch的持久化方案
gateway 代表 elasticsearch 索引的持久化存储方式，elasticsearch 默认是先把索引存放到内存中去，当内存满了的时候再持久化到硬盘里。当这个 elasticsearch 集群关闭或者再次重新启动时就会从 gateway 中读取索引数据。elasticsearch 支持多种类型的 gateway，有本地文件系统（默认），分布式文件系统，Hadoop 的 HDFS 和 amazon 的 s3 云存储服务。
ElasticSearch是先把索引的内容保存到内存之中，当内存不够时再把索引持久化到硬盘中，同时它还有一个队列，是在系统空闲时自动把索引写到硬盘中。
B、Redis数据库
1.Redis简介
redis是开源BSD许可高级的key-value存储系统(NoSQL)，可以用来存储字符串，哈希结构，链表，集合，因此，常用来提供数据结构服务，Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加 载进行使用。 支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。Redis支持数据的备份，即master-slave模式的数据备份。
2.Redis应用场景
A）常规计数：粉丝数，微博数
B）用户信息变更
C）缓存处理，作为mysql的缓存
D）队列系统，建有优先级的队列系统，日志收集系统
3.Redis的优缺点
优点：
(1) 速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)
(2) 支持丰富数据类型，支持string，list，set，sorted set，hash
(3) 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
(4) 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除
缺点：
（1）Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复
（2）主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性
（3）redis的主从复制采用全量复制，复制过程中主机会fork出一个子进程对内存做一份快照，并将子进程的内存快照保存为文件发送给从机，这一过程需要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，而且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行，也就是网络波动都会造成主机和从机间的一次全量的数据复制，这对实际的系统运营造成了不小的麻烦
（4）Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。
4.Redis的持久化方案
redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
C、Mongodb数据库
1.Mongodb简介
MongoDB本身是一种非关系型数据库。它的每一条记录是一个Document，每个Document有一组键值对组成。MongoDB中的Document与JSON对象相似。 Document中字段的值可能包括其他Document，数组等。
2.Mongodb应用场景
mongodb的主要目标是在键/值存储方式（提供了高性能和高度伸缩性）以及传统的RDBMS系统（丰富的功能）架起一座桥梁，集两者的优势于一身。mongo适用于以下场景：
a.网站数据：mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
b.缓存：由于性能很高，mongo也适合作为信息基础设施的缓存层。在系统重启之后，由mongo搭建的持久化缓存可以避免下层的数据源过载。
c.大尺寸、低价值的数据：使用传统的关系数据库存储一些数据时可能会比较贵，在此之前，很多程序员往往会选择传统的文件进行存储。
d.高伸缩性的场景：mongo非常适合由数十或者数百台服务器组成的数据库。
e.用于对象及JSON数据的存储：mongo的BSON数据格式非常适合文档格式化的存储及查询。
3.Mongodb的优缺点
优点：
(1) 弱一致性（最终一致），更能保证用户的访问速度
(2) 文档结构的存储方式，能够更便捷的获取数据
(3) 内置GridFS，支持大容量的存储
(4) 在使用场合下，千万级别的文档对象，近10G的数据，对有索引的ID的查询不会比mysql慢，而对非索引字段的查询，则是全面胜出。
缺点：
（1）不支持事物
（2）占用空间过大，会造成磁盘浪费
（3）单机可靠性比较差
（4）大数据量持续插入，写入性能有较大波动
4.Mongodb的持久化方案/异常处理
当执行写操作时，MongoDB创建一个journal来包含确切磁盘位置和改变的字节。因此，如果服务器突然崩溃，启动时，journal会重放崩溃前并没有刷新到磁盘上的任何写操作。
数据文件每隔60s刷新到磁盘上，默认情况下，因此journal只需要持有60s内的写入数据。journal预分配了几个空文件用于此目的，位于/data/db/journal，命名为_j.0,j.1等等。
MongoDB运行很长时间情况下，在journal目录下，你会看到类似于_j.6217,_j.6218和_j.6219文件。这些文件是当前的journal文件，如果MongoDB一直运行，这些数字会持续增加。当正常关闭MongoDB时，这些文件将被清除，因为正常关机不在需要这些日志的。
如果服务器崩溃或kill -9, mongodb再次启动时，会重放journal文件，会输出冗长难懂的检验行，这表明在正常的恢复。
D、Mysql分布式集群
1.Mysql分布式集群简介
MySQL集群是一个无共享的(shared-nothing)、分布式节点架构的存储方案，其目的是提供容错性和高性能。
数据更新使用读已提交隔离级别（read-committedisolation)来保证所有节点数据的一致性，使用两阶段提交机制（two-phasedcommit)保证所有节点都有相同的数据(如果任何一个写操作失败，则更新失败）。
无共享的对等节点使得某台服务器上的更新操作在其他服务器上立即可见。传播更新使用一种复杂的通信机制，这一机制专用来提供跨网络的高吞吐量。
通过多个MySQL服务器分配负载，从而最大程序地达到高性能，通过在不同位置存储数据保证高可用性和冗余。
2.Mysql分布式集群应用场景
解决海量存储问题，比如京东B2B就用的Mysql分布式集群。
适用几十亿的PV对DB的访问。
3.Mysql分布式集群的优缺点
优点：
a) 高可用性
b)快速的自动失效切换
c)灵活的分布式体系结构，没有单点故障
d)高吞吐量和低延迟
e)可扩展性强，支持在线扩容
缺点：
a)存在很多限制，比如：不支持外键
b)部署、管理、配置很复杂
c)占用磁盘空间大，内存大
d)备份和恢复不方便
e)重启的时候，数据节点将数据load到内存需要很长时间
4.Mysql分布式集群的持久化方案
负载均衡。
管理节点备份。