1. Redis 和 Memcached 各有什么优缺点，主要的应用场景是什么样的
Redis 和 Memcache 都是基于内存的数据存储系统。Memcached是高性能分布式内存缓存服务；Redis是一个开源的key-value存储系统。与Memcached类似，Redis将大部分数据存储在内存中，支持的数据类型包括：字符串、哈希 表、链表、等数据类型的相关操作。下面我们来进行来看一下redis和memcached的区别。权威比较
Redis的作者Salvatore Sanfilippo曾经对这两种基于内存的数据存储系统进行过比较：
Redis支持服务器端的数据操作：Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作，通常在Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。
内存使用效率对比：使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。
性能对比：由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。
具体为什么会出现上面的结论，以下为收集到的资料：
1、数据类型支持不同
与Memcached仅支持简单的key-value结构的数据记录不同，Redis支持的数据类型要丰富得多。最为常用的数据类型主要由五种：String、Hash、List、Set和Sorted Set。Redis内部使用一个redisObject对象来表示所有的key和value。redisObject最主要的信息如图所示：
type代表一个value对象具体是何种数据类型，encoding是不同数据类型在redis内部的存储方式，比如：type=string代表value存储的是一个普通字符串，那么对应的encoding可以是raw或者是int，如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的，当然前提是这个字符串本身可以用数值表示，比如:”123″ “456”这样的字符串。只有打开了Redis的虚拟内存功能，vm字段字段才会真正的分配内存，该功能默认是关闭状态的。
1）String
常用命令：set/get/decr/incr/mget等；
应用场景：String是最常用的一种数据类型，普通的key/value存储都可以归为此类；
实现方式：String在redis内部存储默认就是一个字符串，被redisObject所引用，当遇到incr、decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。
2）Hash
常用命令：hget/hset/hgetall等
应用场景：我们要存储一个用户信息对象数据，其中包括用户ID、用户姓名、年龄和生日，通过用户ID我们希望获取该用户的姓名或者年龄或者生日；
实现方式：Redis的Hash实际是内部存储的Value为一个HashMap，并提供了直接存取这个Map成员的接口。如图所示，Key是用户ID, value是一个Map。这个Map的key是成员的属性名，value是属性值。这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据。当前HashMap的实现有两种方式：当HashMap的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，这时对应的value的redisObject的encoding为zipmap，当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。
3）List
常用命令：lpush/rpush/lpop/rpop/lrange等；
应用场景：Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现；
实现方式：Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。
4）Set
常用命令：sadd/spop/smembers/sunion等；
应用场景：Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的；
实现方式：set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。
5）Sorted Set
常用命令：zadd/zrange/zrem/zcard等；
应用场景：Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set数据结构，比如twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。
实现方式：Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。
2、内存管理机制不同
在Redis中，并不是所有的数据都一直存储在内存中的。这是和Memcached相比一个最大的区别。当物理内存用完时，Redis可以将一些很久没用到的value交换到磁盘。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中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。 这里就存在一个I/O线程池的问题。在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。这种策略在客户端的数量较小，进行批量操作的时候比较合适。但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。
对于像Redis和Memcached这种基于内存的数据库系统来说，内存管理的效率高低是影响系统性能的关键因素。传统C语言中的malloc/free函数是最常用的分配和释放内存的方法，但是这种方法存在着很大的缺陷：首先，对于开发人员来说不匹配的malloc和free容易造成内存泄露；其次频繁调用会造成大量内存碎片无法回收重新利用，降低内存利用率；最后作为系统调用，其系统开销远远大于一般函数调用。所以，为了提高内存的管理效率，高效的内存管理方案都不会直接使用malloc/free调用。Redis和Memcached均使用了自身设计的内存管理机制，但是实现方法存在很大的差异，下面将会对两者的内存管理机制分别进行介绍。
Memcached默认使用Slab Allocation机制管理内存，其主要思想是按照预先规定的大小，将分配的内存分割成特定长度的块以存储相应长度的key-value数据记录，以完全解决内存碎片问题。Slab Allocation机制只为存储外部数据而设计，也就是说所有的key-value数据都存储在Slab Allocation系统里，而Memcached的其它内存请求则通过普通的malloc/free来申请，因为这些请求的数量和频率决定了它们不会对整个系统的性能造成影响Slab Allocation的原理相当简单。 如图所示，它首先从操作系统申请一大块内存，并将其分割成各种尺寸的块Chunk，并把尺寸相同的块分成组Slab Class。其中，Chunk就是用来存储key-value数据的最小单位。每个Slab Class的大小，可以在Memcached启动的时候通过制定Growth Factor来控制。假定图中Growth Factor的取值为1.25，如果第一组Chunk的大小为88个字节，第二组Chunk的大小就为112个字节，依此类推。
当Memcached接收到客户端发送过来的数据时首先会根据收到数据的大小选择一个最合适的Slab Class，然后通过查询Memcached保存着的该Slab Class内空闲Chunk的列表就可以找到一个可用于存储数据的Chunk。当一条数据库过期或者丢弃时，该记录所占用的Chunk就可以回收，重新添加到空闲列表中。
从以上过程我们可以看出Memcached的内存管理制效率高，而且不会造成内存碎片，但是它最大的缺点就是会导致空间浪费。因为每个Chunk都分配了特定长度的内存空间，所以变长数据无法充分利用这些空间。如图 所示，将100个字节的数据缓存到128个字节的Chunk中，剩余的28个字节就浪费掉了。
Redis的内存管理主要通过源码中zmalloc.h和zmalloc.c两个文件来实现的。Redis为了方便内存的管理，在分配一块内存之后，会将这块内存的大小存入内存块的头部。如图所示，real_ptr是redis调用malloc后返回的指针。redis将内存块的大小size存入头部，size所占据的内存大小是已知的，为size_t类型的长度，然后返回ret_ptr。当需要释放内存的时候，ret_ptr被传给内存管理程序。通过ret_ptr，程序可以很容易的算出real_ptr的值，然后将real_ptr传给free释放内存。
Redis通过定义一个数组来记录所有的内存分配情况，这个数组的长度为ZMALLOC_MAX_ALLOC_STAT。数组的每一个元素代表当前程序所分配的内存块的个数，且内存块的大小为该元素的下标。在源码中，这个数组为zmalloc_allocations。zmalloc_allocations[16]代表已经分配的长度为16bytes的内存块的个数。zmalloc.c中有一个静态变量used_memory用来记录当前分配的内存总大小。所以，总的来看，Redis采用的是包装的mallc/free，相较于Memcached的内存管理方法来说，要简单很多。
3、数据持久化支持
Redis虽然是基于内存的存储系统，但是它本身是支持内存数据的持久化的，而且提供两种主要的持久化策略：RDB快照和AOF日志。而memcached是不支持数据持久化操作的。
1）RDB快照
Redis支持将当前数据的快照存成一个数据文件的持久化机制，即RDB快照。但是一个持续写入的数据库如何生成快照呢？Redis借助了fork命令的 on write机制。在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件。我们可以通过Redis的save指令来配置RDB快照生成的时机，比如配置10分钟就生成快照，也可以配置有1000次写入就生成快照，也可以多个规则一起实施。这些规则的定义就在Redis的配置文件中，你也可以通过Redis的CONFIG SET命令在Redis运行时设置规则，不需要重启Redis。
Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的，当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件，这样在任何时候出现故障，Redis的RDB文件都总是可用的。同时，Redis的RDB文件也是Redis主从同步内部实现中的一环。RDB有他的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。在某些业务下，这是可以忍受的。
2）AOF日志
AOF日志的全称是append only file，它是一个追加写入的日志文件。与一般数据库的binlog不同的是，AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令。只有那些会导致数据发生修改的命令才会追加到AOF文件。每一条修改数据的命令都生成一条日志，AOF文件会越来越大，所以Redis又提供了一个功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了对同一个值的多次操作。其生成过程和RDB类似，也是fork一个进程，直接遍历数据，写入新的AOF临时文件。在写入新文件的过程中，所有的写操作日志还是会写到原来老的AOF文件中，同时还会记录在内存缓冲区中。当重完操作完成后，会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的rename命令用新的AOF文件取代老的AOF文件。
AOF是一个写文件操作，其目的是将操作日志写到磁盘上，所以它也同样会遇到我们上面说的写操作的流程。在Redis中对AOF调用write写入后，通过appendfsync选项来控制调用fsync将其写到磁盘上的时间，下面appendfsync的三个设置项，安全强度逐渐变强。
appendfsync no 当设置appendfsync为no的时候，Redis不会主动调用fsync去将AOF日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。
appendfsync everysec 当设置appendfsync为everysec的时候，Redis会默认每隔一秒进行一次fsync调用，将缓冲区中的数据写到磁盘。但是当这一次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略，再等一秒钟。也就是在两秒后再进行fsync，这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞，所以当前的写操作就会阻塞。所以结论就是，在绝大多数情况下，Redis会每隔一秒进行一次fsync。在最坏的情况下，两秒钟会进行一次fsync操作。这一操作在大多数数据库系统中被称为group commit，就是组合多次写操作的数据，一次性将日志写到磁盘。
appednfsync always 当设置appendfsync为always时，每一次写操作都会调用一次fsync，这时数据是最安全的，当然，由于每次都会执行fsync，所以其性能也会受到影响。
对于一般性的业务需求，建议使用RDB的方式进行持久化，原因是RDB的开销并相比AOF日志要低很多，对于那些无法忍数据丢失的应用，建议使用AOF日志。
4、集群管理的不同
Memcached是全内存的数据缓冲系统，Redis虽然支持数据的持久化，但是全内存毕竟才是其高性能的本质。作为基于内存的存储系统来说，机器物理内存的大小就是系统能够容纳的最大数据量。如果需要处理的数据量超过了单台机器的物理内存大小，就需要构建分布式集群来扩展存储能力。
Memcached本身并不支持分布式，因此只能在客户端通过像一致性哈希这样的分布式算法来实现Memcached的分布式存储。下图给出了Memcached的分布式存储实现架构。当客户端向Memcached集群发送数据之前，首先会通过内置的分布式算法计算出该条数据的目标节点，然后数据会直接发送到该节点上存储。但客户端查询数据时，同样要计算出查询数据所在的节点，然后直接向该节点发送查询请求以获取数据。
相较于Memcached只能采用客户端实现分布式存储，Redis更偏向于在服务器端构建分布式存储。最新版本的Redis已经支持了分布式存储功能。Redis Cluster是一个实现了分布式且允许单点故障的Redis高级版本，它没有中心节点，具有线性可伸缩的功能。下图给出Redis Cluster的分布式存储架构，其中节点与节点之间通过二进制协议进行通信，节点与客户端之间通过ascii协议进行通信。在数据的放置策略上，Redis Cluster将整个key的数值域分成4096个哈希槽，每个节点上可以存储一个或多个哈希槽，也就是说当前Redis Cluster支持的最大节点数就是4096。Redis Cluster使用的分布式算法也很简单：crc16( key ) % HASH_SLOTS_NUMBER。
为了保证单点故障下的数据可用性，Redis Cluster引入了Master节点和Slave节点。在Redis Cluster中，每个Master节点都会有对应的两个用于冗余的Slave节点。这样在整个集群中，任意两个节点的宕机都不会导致数据的不可用。当Master节点退出后，集群会自动选择一个Slave节点成为新的Master节点。
发布于 2017-02-09
241 条评论
分享
收藏感谢收起
张光宇
none
10 人赞同了该回答
先说Redis的特点
Redis 有各种丰富的数据结构，如果和业务对口，用起来会非常方便（比如Timeline, JobQueue等场合）。
Redis支持数据持久化，虽然无法像数据库那样完善，但对于互联网这种场景，完全够用了。
Memcached的特点
纯粹的cache，意思是一般只会expire cache而不会修改(或append)cache。区别就在于，你fetch的时候总会考虑cache missing的情况。
作为cache时，关于性能比较
两者都经过了良好的设计，在0～300个client的并发GET/SET下，throughput 都在保持在10万/秒以上。
memcached的性能比redis要好很多(数倍)，这也比较容易理解。但往往瓶颈会在client或者网络等地方。
这里是benchmark
2. 手机的系统主要有哪几种各个系统的优缺点是什么
目前应用在手机上的操作系统主要有PalmOS、Symbian、WindowsCE、Linux和Android、iPhoneOS六种，其中采用Symbian、WindowsCE和Android的手机较多，Linux和Palm对应的软件非常少见。在国内，安装有Symbian操作系统的手机多为诺基亚生产，酷派、多普达则是WindowsMobile的主要支持者，代表产品有酷派N900+（WindowsCE6.0操作系统）、酷派F800（WindowsCE6.0操作系统）、等。
Symbian系统
Symbian是一个实时性、多任务的纯32位操作系统，具有功耗低、内存占用少等特点，非常适合手机等移动设备使用，经过不断完善，可以支持GPRS、蓝牙、SyncML、以及3G技术。最重要的是它是一个标准化的开放式平台，任何人都可以为支持Symbian的设备开发软件。与微软产品不同的是，Symbian将移动设备的通用技术，也就是操作系统的内核，与图形用户界面技术分开，能很好的适应不同方式输入的平台，也可以使厂商可以为自己的产品制作更加友好的操作界面，符合个性化的潮流，这也是用户能见到不同样子的Symbian系统的主要原因。现在为这个平台开发的java程序已经开始在互联网上盛行。用户可以通过安装这些软件，扩展手机功能。
在Symbian发展阶段，出现了三个分支：分别是Crystal、Pearl和Quarz。前两个主要针对通讯器市场，也是出现在手机上最多的，是今后智能手机操作系统的主力军。第一款基于Symabian系统的手机是2000年上市的爱立信R380手机。而真正较为成熟的同时引起人们注意的则是2001年上市的诺基亚9210，它采用了Crystal分支的系统。而2002年推出的诺基亚7650与3650则是SymbianPearl分系的机型，其中7650是第一款基于2.5G网的智能手机产品，他们都属于Symbian的6.0版本。索尼爱立信推出的一款机型也使用了Symbian的Pearl分支，版本已经发展到7.0，是专为3G网络而开发的，而目前的诺基亚已经达到8.0的6630、6681等，可以说代表了当今最强大的手机操作系统。此外，Symbian从6.0版本就开始支持外接存储设备，如MMC卡，这让它强大的扩展能力得以充分发挥，使存放更多的软件以及各种大容量的多媒体文件成为了可能。
Windows Mobile系统
WindowsMobile系统包括PocketPC和Smartphone以及MediaCenters，PocketPC针对无线PDA，Smartphone专为手机，已有多个来自IT业的新手机厂商使用，增长率较快。
按照微软官方的说法：“WindowsMobile将熟悉的Windows体验扩展到了移动环境中，所以您可以立即使用它投入工作。”
事实上，WindowsMobile是微软进军移动设备领域的重大品牌调整，它包括PocketPC、Smartphone以及MediaCenters三大平台体系，面向个人移动电子消费市场。由于大多数机型支持彩色显示，因此耗电量极大，并且由于WindowsCE本身对于资源的巨大吞噬作用。在功能扩展方面微软比较倾向于集成使用，大多具有标准的CF卡插槽，用户可以根据自己的需要增加内存、加装摄像头、调制解调器等设备。
微软为手机而专门开发的WindowsMobile提供的功能非常多，在不同的平台上实现的功能互有重叠也各有侧重。这三个平台都支持和台式机的数据同步。Smartphone提供的功能侧重点在联系方面，它主要支持的功能有：电话、电子邮件、联系人、即时消息。PocketPC的功能侧重个人事务处理和简单的娱乐，主要支持的功能有：日程安排、移动版Office，简单多媒体播放功能。
Linux系统
Linux系统是一个源代码开放的操作系统，目前已经有很多版本流行。但尚未得到较广泛的支持。
Linux进入到移动终端操作系统近一年多时间，就以其开放源代码的优势吸引了越来越多的终端厂商和运营商对它的关注，包括摩托罗拉和NTTDoCoMo等知名的厂商。已经开发出的基于Linux的手机有摩托罗拉的A760、A768、CEC的e2800、三星的i519等。2004年6月在日本东京BIGSIGHT展览馆举办的“LinuxWorldExpo/Tokyo2004”博览会上，日本手机大厂商NEC则展示了其采用Linux操作系统的手机。我国的大唐电信也于7月宣布将Linux作为其TD-SCDMA3G手机操作系统。
Linux与其它操作系统相比是个后来者，但Linux具有二个其它操作系统无法比拟的优势。其一，Linux具有开放的源代码，能够大大降低成本。其二，既满足了手机制造商根据实际情况有针对性地开发自己的Linux手机操作系统的要求，又吸引了众多软件开发商对内容应用软件的开发，丰富了第三方应用。
然而Linux操作系统有其先天的不足：入门难度高、熟悉其开发环境的工程师少、集成开发环境较差；由于微软PC操作系统源代码的不公开，基于Linux的产品与PC的连接性较差；尽管目前从事Linux操作系统开发的公司数量较多，但真正具有很强开发实力的公司却很少，而且这些公司之间是相互独立的开发，很难实现更大的技术突破。
尽管Linux在技术和市场方面有独到的优势，但是目前来说还无法与Symbian抗衡，想在竞争日益激烈的手机市场中站稳脚跟、抢夺市场份额也决非易事。
Palm OS
这是一种32位的嵌入式操作系统，主要运用于移动终端上。此系统最初由3Com公司的PalmComputing部开发，目前PalmComputing已经独立成一家公司。PalmOS与同步软件HotSync结合可以使移动终端与电脑上的信息实现同步，把台式机的功能扩展到了移动设备上。
PalmOS操作系统由Palm公司自行开发的，并授权给Handspring、索尼和高通等设备厂家，这种操作系统更倾向于PDA的操作系统。
PalmOS在PDA市场占有主导地位。Palm的产品线本身就包括智能手机，又宣布与最早的智能手机开发者Handspring购并，同时将软件部门独立。
Android系统
这是Google开发的基于Linux平台的开源手机操作系统。它包括操作系统、用户界面和应用程序——移动电话工作所需的全部软件，而且不存在任何以往阻碍移动产业创新的专有权障碍。Google与开放手机联盟合作开发了Android，这个联盟由包括中国移动、摩托罗拉、高通、宏达电和T-Mobile在内的30多家技术和无线应用的领军企业组成。Google通过与运营商、设备制造商、开发商和其他有关各方结成深层次的合作伙伴关系，希望借助建立标准化、开放式的移动电话软件平台，在移动产业内形成一个开放式的生态系统。
Android作为谷歌企业战略的重要组成部分，将进一步推进"随时随地为每个人提供信息"这一企业目标的实现。我们发现，全球为数众多的移动电话用户从未使用过任何基于Android的电话。谷歌的目标是让（移动通讯）不依赖于设备甚至平台。出于这个目的，Android将补充，而不会替代谷歌长期以来奉行的移动发展战略：通过与全球各地的手机制造商和移动运营商结成合作伙伴，开发既有用又有吸引力的移动服务，并推广这些产品。
3. 有没有用Java写的轻量级开源的分布式存储系统
以下内容源于分布式内存文件系统：Tachyon 14年9月的文章
Tachyon是一个分布式内存文件系统，可以在集群里以访问内存的速度来访问存在tachyon里的文件。把Tachyon是架构在最底层的分布式文件存储和上层的各种计算框架之间的一种中间件。主要职责是将那些不需要落地到DFS里的文件，落地到分布式内存文件系统中，来达到共享内存，从而提高效率。同时可以减少内存冗余，GC时间等。
<img src="https://pic3.mg.com/_b.png" data-rawwidth="810" data-rawheight="311" class="origin_image zh-lightbox-thumb" width="810" data-original="https://pic3.mg.com/_r.png">
Tachyon架构
Tachyon的架构是传统的Master—slave架构，这里和Hadoop类似，TachyonMaster里WorkflowManager是 Master进程，因为是为了防止单点问题，通过Zookeeper做了HA，可以部署多台Standby Master。Slave是由Worker Daemon和Ramdisk构成。这里个人理解只有Worker Daemon是基于JVM的，Ramdisk是一个off heap memory。Master和Worker直接的通讯协议是Thrift。
下图来自Tachyon的作者Haoyuan Li：
<img src="https://pic4.mg.com/_b.png" data-rawwidth="854" data-rawheight="571" class="origin_image zh-lightbox-thumb" width="854" data-original="https://pic4.mg.com/_r.png">
三、Fault Tolerant
Tachyon是一个分布式文件存储系统，但是如果Tachyon里的容错机制是怎么样的呢？
Tachyon使用血统这个我们在Spark里的RDD里已经很熟悉了，这里也有血统这一概念。会使用血统，通过异步的向Tachyon的底层文件系统做Checkpoint。
当我们向Tachyon里面写入文件的时候，Tachyon会在后台异步的把这个文件给checkpoint到它的底层存储，比如HDFS，S3.. etc...
这里用到了一个Edge的算法，来决定checkpoint的顺序。
比较好的策略是每次当前一个checkpoint完成之后，就会checkpoint一个最新生成的文件。当然想Hadoop，Hive这样的中间文件，需要删除的，是不需要checkpoint的。
下图来自Tachyon的作者Haoyuan Li：
<img src="https://pic1.mg.com/_b.png" data-rawwidth="822" data-rawheight="609" class="origin_image zh-lightbox-thumb" width="822" data-original="https://pic1.mg.com/_r.png">
关于重新计算时，资源的分配策略：
目前Tachyon支持2种资源分配策略：
1、优先级的资源分配策略
2、公平调度的分配策略
<img src="https://pic2.mg.com/_b.png" data-rawwidth="940" data-rawheight="621" class="origin_image zh-lightbox-thumb" width="940" data-original="https://pic2.mg.com/_r.png">
四、总结
Tachyon是一个基于内存的分布式文件系统，通常位于分布式存储系统和计算框架直接，可以在不同框架内共享内存，同时可以减少内存冗余和基于Jvm内存计算框架的GC时间。
Tachyon也有类似RDD的血统概念，input文件和output文件都是会有血统关系，这样来达到容错。并且Tachyon也利用血统关系，异步的做checkpoint，文件丢失情况下，也能利用两种资源分配策略来优先计算丢失掉的资源。
4. Ceph为什么越来越火国内使用ceph较为成功的存储厂商有哪些
Ceph是当前非常流行的开源分布式存储系统，具有高扩展性、高性能、高可靠性等优点，同时提供块存储服务(rbd)、对象存储服务(rgw)以及文件系统存储服务(cephfs)。目前也是OpenStack的主流后端存储，随着OpenStack在云计算领域的广泛使用，ceph也变得更加炙手可热。国内目前使用ceph搭建分布式存储系统较为成功的企业有x-sky,深圳元核云，上海UCloud等三家企业。
5. 的云存储系统，问下现在有什么比较常用的开源分布式
书生云于宣布将基于SAS架构的新一代开源分布式存储技术——SurFS开源。SurFS是书生云公司自主研发的分布式存储系统，是云平台的核心部件，在性能和成本两方面具有一定实力。书生云将具有自身知识产权的商业软件开源，对软件行业将带来哪些影响? 书生云董事长王东临 众所周知，开源软件技术领域较为知名的除了Android(安卓)、Linux、MySQL、OpenOffice、OpenStack等开源社区外，企业级领域软件开源的并不算多，但也能看到其中一些卓越领导者，比如知名开源软件企业 RedHat， RedHat的年收入甚至超过了20亿美元。 因此，书生云董事长王东临认为：“虽然在视核心技术商业机密的传统思维里，软件企业将自身拥有知识产权的软件的开源显得另类，但随着开源系统在全球的广泛普及，未来开源与商业也会得到完美结合，形成了“先奉献后收益”、“贡献越大收益越大”的格局。” 存储系统是云平台的核心部件，对云平台的整体性能和成本都有极大的影响。SurFS通过对存储网络的颠覆式创新，第一个采用SAS做存储网络构建分布式存储系统，将带宽提升了几十倍延时降低了几十倍，而且从架构体系上完全打破了传统存储体系的桎梏，将存储控制节点与存储介质分离，存储控制节点与计算节点聚合，从而将数据I/O路径压缩到了极致，将扩容成本也压缩到了极致，大幅提升了整个云平台的性能，同时还显着降低了成本，同时实现高性能、低成本、高可靠、高可用和可扩展性。对于正在向私有云迁移的广大企业级用户来说，SurFS的确有着很大的优越性。 笔者小结 书生云基于SAS存储网络构建的新一代开源分布式存储SurFS 开源后将成为OpenStack等主流云平台的存储后端之一，对于广大IT工程师和终端用户来说，更无异是一针强心剂，开源社区在得到完善管理的前提下，对于未来的存储技术及应用会有更加加速的发展。SurFS 开源将为全球企业级用户搭建高性价比的云平台，并为广大IT企业提供一个切磋、改善行业价值链的机遇的开源，基于SurFS技术的云平台有望成为全球云产业的主流部署模式之一。 当然，书生云的SurFS 开源仍然只是国内软件业的起步!无论是业务模式的探索还是开源后社区的维护，还需要时间及智慧来推进。
6. 目前国内有公司在使用开源的ceph分布式存储系统吗
有，我知道的使用ceph的公司主要有元核云、XSky、杉岩数据等，其他的华为云、深信服等公司也有分布式存储，不过不知道是不是基于ceph的。
7. 如何搭建私有云存储
虚拟化技术在企业私有云IT基础架构中仍然占据重要地位，同时，为了进一步提升应用效率，越来越多的生产环境也正在逐步变革，从以虚拟机为中心的架构向以容器和微服务为中心的云原生架构过渡，在这个过程中，存储如何有效支撑各种云主机应用与微服务应用，对于企业的私有云数据中心提出了新的挑战。
企业面临的问题
存储设施七国八制，硬件锁定缺少弹性
多种云平台对于存储的要求各不相同，块/文件/对象存储对应不同类型的应用，对外提供不同的服务接口，一种存储设备无法满足多种类型的云平台存储需求，而且传统存储在扩展性方面不能满足云时代大规模云平台对存储在线弹性扩容的需求，在可维护性方面则面临硬件架构绑定、运维复杂、难以维保等问题，而且这些问题会随着存储设备种类和数量的增多进一步放大。
业务调度变更频繁，资源不能共享
随着开发测试虚拟机以及容器、微服务平台在企业私有云平台的上线，大型企业的应用快速迭代、频繁发布对存储系统的支撑提出了严峻挑战，不同业务的数据保存在不同厂商的存储设备中，数据流动性差，不仅导致存储空间及性能资源浪费严重，数据灾备方案也很难统一化。
开源产品难以维护，不能实现企业级产品化
基于开源虚拟化技术的云平台如OpenStack为众多客户提供了快速构建私有云基础设施的能力，但是存储部分却不一样，开源的存储系统如Ceph虽然可以小规模部署试用， 但在大规模商用时会遇到很多问题：与硬件和企业级应用生态融合程度不高，严重依赖人工开发运维，在性能和服务质量方面不能满足核心业务的需求
杉岩私有云存储解决方案
杉岩私有云存储解决方案充分发挥了杉岩统一存储平台（USP）的云适配、开放等优势，支持各种复杂的应用负载，可灵活支撑私有云的虚拟化平台，如VMware、Citrix、OpenStack等虚拟化和云平台，以及通过Kubernetes软件一致性认证的所有容器云平台，如：Rancher、Openshift、Kubernetes等。
通过杉岩统一存储平台，用户可快速构建能够兼容所有主流虚拟化平台与容器微服务平台的统一存储资源池，面对各种虚拟机和微服务需求，池化的存储平台为大规模云环境提供了可靠的存储基础架构支撑，帮助用户从纷繁复杂的基础架构运维工作中解放出来，更关注于私有云上运行的业务本身。
客户价值
资源整合，链接企业信息孤岛
单资源池提供块、文件、对象多种存储服务，支持虚拟化平台和数据库应用；强大的存储资源生命周期管理能力，跨云平台在线迁移数据，实现数据共享和提高资源利用率；存储卷QoS等级和性能优先级在线调整，可根据企业资源和业务需求合理配置资源。
开放兼容，适配多种私有云平台
通过VMware VAAI和Citrix Ready认证，针对主流虚拟化平台优化I/O性能，大幅提升虚拟机访问的性能。通过OpenStack Cinder认证，可提供块和对象存储基础架构支撑支持容器平台CSI接口认证，为Kubernetes生态的容器应用提供块和文件存储服务。
智能管理，解决规模化运维难题
向导式安装部署和自助扩容配置，极大提升易用性和可维护性，管理自动化降低运维成本；针对大规模集群优化的可靠性管理，检测和修复硬盘软错误的专利技术，节约用户硬件投资。存储视角的管理功能，可视化展示主机、容器与存储的映射关系和性能监控协助管理员快速定位和解决问题。
8. 国内较好的分布式云存储产品有哪些
阿里云的分布式存储系统盘古是自主研发的代表，支撑了大多数阿里云的存储和计算产品。
网络，github上有个开源的分布式文件系统，但是感觉跟工业级差别比较大。
腾讯，PaxosStore应该算一个。
华为，好多做存储的团队，有使用开源的，有自研的。
云科数据，YK4000及YK6000的两款超融合一体机的市场前景颇为看好，这与其行业领先、与世界同步的技术优势不无关系，采用了核心分布式存储软件EMC ScaleIO，搭建起与谷歌、Facebook、亚马逊等 Web大规模的公有云相同的基础架构。
大公司应该都有能力和资源自己写分布式存储系统，就看如何打磨得更适合自己的业务特点了。