kv存储系统是什么

① 一般什么产品或者系统或网站会使用K/V数据库型数据库呢

KV型存储系统是最常用的Nosql存储系统之一。Memcached和Redis是其最具代表的两个产品。本文将详细介绍Memcached和Redis的常用场景及如何构建一个高可用和自动弹性伸缩的KV存储系统。

Cache加DB是最常见的存储层架构。时间局部性原理指出正在被访问的数据很可能会在近期再次被访问。根据这一原理应用程序将最近访问过的数据保存在Cache中，每次读取请求首先访问Cache，若Cache中保存有该数据则直接获取数据返回给前端。若Cache中该数据不存在则从DB获取数据并将该数据保存到Cache；若数据被更新或删除则将Cache中对应数据置为失效。使用Cache能够很好地缓解DB的读请求压力。KV存储系统既可以应用在Cache层也可以应用在DB层。

Memcached使用内存作为存储介质，因为内存数据的易失性Memcached主要应用在Cache层。Memcached常见的应用场景是存储一些读取频繁但更新较少的数据，如静态网页、系统配置及规则数据、活跃用户的基本数据和个性化定制数据、准实时统计信息等。并不是所有场景都适合Memcached加DB的架构，在某些场景下这一架构存在一些局限。例如这一架构不能提升写的性能，写数据时还是数据直接存储到DB，同时需要将Cache中数据置为失效，所以对以写请求为主的应用使用Cache提升性能的效果并不是很明显。如果应用的热点数据或者活跃用户分布较为分散也会降低Cache的命中率。如果遇到机器宕机，内存数据会丢失，那么机器重启后需要一段时间重新建立热点数据，建立热点数据的过程中会对DB会造成较大的压力，严重时会导致系统雪崩。

相比Memcached，Redis做了一些优化。首先，Redis对数据做了持久化，支持AOF和RDB两种持久化方式，机器重启后能通过持久化数据自动重建内存。其次，Redis支持主从复制，主机会自动将数据同步到从机，可以进行读写分离，主机负责写操作，从机负责读操作。那样既增加了系统的读写性能又提升了数据的可靠性。再次，Redis除了支持string类型的value外还支持string、hash、set、sorted set、list等类型的数据结构。因此，Redis既可以应用在Cache层，也可以替换或者部分替换DB存储持久化数据。使用Redis作为Cache时机器宕机后热点数据不会丢失，无须像Memcached一样重建热点数据。相比Cache加DB的架构方式，使用Redis存储持久化数据不仅能够提升读性能，还能提升写性能，而且不存在热点数据分布是否集中而影响命中率的问题。Redis丰富的数据结构也使其拥有更加丰富的应用场景。Redis的命令都是原子性的，可以简单地利用INCR和DECR实现计数功能。使用list可以实现获取最近N个数的操作。sort set支持对数据排序，可以应用在排行榜中。set集合可以应用到数据排重。Redis还支持过期时间设置，可以应用到需要设定精确过期时间的应用。只要可以使用Redis支持的数据结构表示的场景，就可以使用Redis进行存储。但Redis不是万能的，它不支持关系型数据库复杂的SQL操作。某些场景下，可结合Redis和关系型DB，将简单查询相关的数据保存在Redis中，复杂SQL操作由关系型DB完成。

虽然Redis集很多优点于一身，但在实际运营中也存在一些问题。首先，Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。如果主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。其次，Redis的主从复制采用全量复制，复制过程中主机会fork出一个子进程对内存做一份快照，并将子进程的内存快照保持为文件发送给从机，这一过程需要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，而且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行，也就是网络波动都会造成主机和从机间的一次全量的数据复制，这对实际的系统运营造成了不小的麻烦。最后，Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

② 如何评价ku存储引擎

没有数据分析流式计算的经验，根据对kv存储系统的理解，简单答一发，轻拍。。
数据存储的选择上，HBASE和HADOOP在吞吐率、延迟上各有侧重，如果做数据分析，要从HBase导出到hadoop平台再用Hive查询，这就要求系统要混布HBASE和hadoop。
KADU的目标就是要兼顾前两个存储系统，实现对外数据的存储和后台计算的本地化，减少数据传输成本已经部署运维成本。
架构方面，还是延用BIGTABLE的基本架构，元数据和数据分开存储的，但做了一些比较有挑战的优化操作，提升查询和插入的性能
另外的亮点是，多副本间使用了raft保证数据的高可靠性。
性能方面，目前beta版本要略差与HBASE,这也是意料之中的事情。

③ 怎么指定redis集群节点的主从关系

市面上太多kv的缓存，最常用的就属memcache了，但是memcache存在单点问题，不过小日本有复制版本，但是使用的人比较少，redis的出现让kv内存存储的想法成为现实。今天主要内容便是redis主从实现简单的集群，实际上redis的安装配置砸门ttlsa之前就有个文章，废话少说，进入正题吧

Redis简介

redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、 list(链表)、set(集合)和zset(有序集合)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操 作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的 是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。它提供了Python，Ruby，Erlang，PHP客户端，使用很方便。

 

1. 下载软件包

# cd /usr/local/src/

# wget http://redis.googlecode.com/files/redis-2.6.11.tar.gz

2. Redis安装

主从都需要安装

# tar -xzvf redis-2.6.11.tar.gz

# mv redis-2.6.11 /usr/local/

# cd /usr/local/redis-2.6.11/

# make

备注：这边就不make install 了，直接使用make好的文件

3. redis配置

找到配置文件/usr/local/redis-2.6.11/redis.conf

修改如下内容：

daemonize no 改为 yes # 是否后台运行

port 6379 改

④ 文件比较”功能的java开源项目吗

一个轻量级分布式KV存储系统。 如果用K记录文件路径和文件名，用V记录文件内容，就是一个轻量级分布式小文件系统。 至于大文件，几乎一定是HDFS这种有元数据服务中心（NameNode）架构的。

⑤ 有没有用Java写的轻量级开源的分布式存储系统

1、jmeter的架构和loadrunner原理一样，都是通过中间代理，监控和收集并发客户端发出的指令，把他们生成脚本，再发送到应用服务器，再监控服务器反馈结果的一个过程；
2、分布式中间代理功能在jmeter中也有，这个分页式代理是指可设置多台代理在不同PC中，通过远程进行控制，即通过使用多台机器运行的谓的agant来分担load generator自身的压力，并借引来获取更大的并发用户数，loadrunner也有此功能；
3、jmeter安装简单，只需要解压jmeter文件包到C盘上就可以了，不用安装，要是你想执行调试测试脚本，前提是：装上jdk和netbean插件，而loadrunner安装包有1G多，在一台P3.0,1G内存的PC上安装要一个多小时，要是装过旧的盗版还不能再装新版，解决办法倒是有，但麻烦且花时间；
4、Jmeter没有IP欺骗功能，IP欺骗是指在一台PC上多个IP地址分配给并发用户，这个功能对于模拟较真实的用户环境来说，是较有用，loadrunner有此功能；
5、jmeter也提供了一个利用本地proxy server(代理服务器)来录制生成测试脚本的功能，但是这个功能并不好用，测试对象的个别参数要手工增加上去，还得附带装个IE代理，如 GoogleToolbarDownloader这些插件来捕捉参数，但是有一个工具badbody,利用这个工具可以录制操作，然后选择将脚本保存为jmeter脚本，然后利用jmeter可以打开并修改脚本；
6、Jmeter的报表较少，对于要分析测试性能不足作为依据。如要知道数据库服务器或应用程序服务的cpu,money等参数，还得在相关服务器上另外写脚本记录服务器的性能；
7、jmeter做性能测试，主要是通过增加线程的数目，或者是设置循环次数来增加并发用户，而loadrunner可以通过在场景中选择要设置什么样的场景，然后选择虚拟用户数；
8、jmeter可以通过逻辑控制器实现复杂的测试行为，相当于loadrunner中的测试场景；
9、jmeter可以做web程序的功能测试，利用jmeter中的样本，可以做灰盒测试，loadrunner主要用来做性能测试；
10、jmeter是开源的，但是使用的人较少，网络上相关资料不全面，需要自己去揣摩，而loadrunner是商业软件，如果是正版本，有技术支持，同时，网络上的资料相当多；
11、Jmeter的脚本修改，主要是针对jmeter中各个部件的熟悉程序，已经相关的一些协议的掌握情况，而不依赖于编程，而loadrunner除了复杂的场景设置外，还需要掌握函数，修改脚本。

⑥ 为什么分布式数据库这么喜欢用kv store

大部分数据库都有KV存储这个抽象，但仍然存在很大的设计空间，例如单机的KV是否需要支持事务，是否需要感知schema，是否需要暴露多版本的接口。因此，不能笼统地说分布式数据库都喜欢用KV store。

分布式数据库系统通常使用较小的计算机系统，每台计算机可单独放在一个地方，每台计算机中都可能有DBMS的一份完整拷贝副本，或者部分拷贝副本，并具有自己局部的数据库，位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。

结构模式

根据我国制定的《分布式数据库系统标准》，分布式数据库系统抽象为4层的结构模式。这种结构模式得到了国内外的支持和认同。

4层模式划分为全局外层、全局概念层、局部概念层和局部内层，在各层间还有相应的层间映射。这种4层模式适用于同构型分布式数据库系统，也适用于异构型分布式数据库系统。

⑦ 如何解决网站架构KV储存问题

• 如果对楼主有帮助，给个采纳可以不，谢谢啦

• Key-value存储系统，是非常普遍的需求，几乎每个在线的互联网后台服务都需要KV存储，我们团队在KV存储方面，经历过几个时期，我自己深感要做好不容易。

• 这里扯远一点，展开说一下：

• 第一个时期，很早期的时候，我们的数据存储在mysql表里，按照用户账号简单的分库分表，为了保证访问高并发，利用每个mysql服务器的内存做数据缓存；主备两套分布在不同IDC，业务逻辑自己做副本同步。当时主要的问题是：内存的数据结构扩展困难、运维工作琐碎、数据同步机制本身的缺陷导致不能做异地IDC部署，这些缺点对于业务飞速发展、一地机房已经不够用的局面非常被动

• 第二个时期，我们设计了新的KV存储系统，其用户数据结构容易扩展、具备可以多地部署的数据同步机制，很好的应对了新时期业务发展的需要。为了设备成本考虑，我们把数据做冷热分离，访问频繁的数据会加载到专门的cache层，且对于不同的访问模型，挂载不同架构的cache，另外一个file层专门做数据持久化。这样的设计，使得架构太复杂，bug收敛速度慢，运维工作相比以前甚至更复杂了。

• 第三个时期，为了应对普遍的KV存储需求，我们以公共组件的形式重新设计了KV存储，作为团队标准的组件之一，得到了大规模的应用。结合同期抽象出来的逻辑层框架、路由管理等其他组件，团队的公共基础组件和运维设施建设的比较完备了，整个业务的开发和运维实现了标准化。但这个阶段就用了我们团队足足2年多时间。

• 不同于无数据的逻辑层框架，KV存储系统的架构设计会更复杂、运维工作更繁琐、运营过程中可能出现的状况更多、bug收敛时间会更长。一句话：团队自己做一个KV存储系统是成本很高的，而且也有比较高的技术门槛。

• 设计一个KV存储，需要考虑至少这些方面：

• 如何组织机器的存储介质，通常是内存、磁盘文件；例如用hash的方式组织内存

• 如何设计用户的数据结构，使得通用、易于扩展、存储利用率高；例如PB序列化、Json、XML方式

• 友好的访问接口，而不只是get / set一整个value

• 如何做集群分布、如何sharding、如何做到方便的扩缩容；例如一致性hash算法

• 如何做数据冗余、副本间如何同步、一致性问题；副本间如何选举master

• 备份与恢复、数据校验与容错

• 读写性能

• 其他可能的特殊需求：例如我们设计过一个KV存储，用于存储一些公众号的个数不受限粉丝列表

上面八点，业内的KV存储组件一般都会考虑到，或者各有特色，各自优势在伯仲之间。但是综合过去的经验教训，我们觉得有一点很容易被忽视：可运维性、运维自动化、黑盒化运维。

举一个例子，前面提到的我们第二个时期的KV存储系统，刚开始应用的时候，一次扩容过程会有10多步的运维操作，包括load数据、做增量同步、多次修改机器状态、数据比对等等，需要运维同事以高度的责任心来完成。另外就是运维同事必须如该KV存储架构设计者一样深刻理解系统背后的原理和细节，否则就不能很好的执行运维操作，这个要求也非常高，新老交接周期长，还容易出运维事故。

基于上面的考虑，同事为了让用户更容易学习和接受，毫秒服务引擎在redis cluster的基础上，实现了运维web化，并加上了集群的监控。

毫秒服务引擎(msec, 取英文名Mass Service Engine in Cluster的首字母组合)是腾讯一个开源框架，其创作冲动和构建经验，来自QQ后台团队超过10年的运营思考。

⑧ 如何实现 Docker 与分布式数据库结合

那么Docker是什么呢?
Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。几乎没有性能开销,可以很容易地在机器和数据中心中运行。最重要的是,他们不依赖于任何语言、框架包括系统。
这是对Docker的一个官方解释，简单说，有两个部分：
1) 对于应用程序，曾经我们需要为了不同的系统专门的调整应用程序的代码或者是构造相应的依赖包驱动等等，大大增加了开发量以及开发的难度。现在，Docker向不同的应用程序，提供了一个统一的环境。
2) 对于服务器，为了支持不同版本的应用，曾经可能需要在物理机上安装多个版本或者不同的GuestOS或者说虚拟机。这就大大占用了物理机的性能，影响了最终程序的表现，提高了资源的成本。

使用Docker容器的方式，对于应用程序，不需要开发多种多样的版本或者是针对OS每个版本的升级再进行代码方面的调整，实现了广泛的兼容性和开发的最简性。同时对于物理机，部署的环境“瘦身”也节约了更多的资源，将更多的资源用于提高应用程序本身的性能。
CoreOS是Docker的不二之选?
之前大概介绍了Docker，那么服务器上面还是需要最基本的应操作系统才能支撑Docker容器，那么这么多中的Linux内核OS究竟哪一个好呢?笔者和很多Docker技术专家的的观点就是Core OS。
CoreOS是一个基于Linux 内核的轻量级操作系统，为了计算机集群的基础设施建设而生，专注于自动化，轻松部署，安全，可靠，规模化。作为一个操作系统，CoreOS 提供了在应用容器内部署应用所需要的基础功能环境以及一系列用于服务发现和配置共享的内建工具。
简单说，CoreOS去掉了大量的非必要的功能，只保留了Server端需要的最基本功能，真正意义做到了“轻量化”。
此外，CoreOS还做到了：整体系统升级/回滚方案;容器化所有非系统应用、无包管理器;集群化调度器Fleet;分布式高可靠的KV存储系统ETCD
这些特性都让它成为Docker生态的首选操作系统。不过最新的消息是，CoreOS不满足于做Docker生态下的一环，它正在推出自己的容器AppC计划，想对Docker来一招“釜底抽薪”。当然，现阶段并没有出现完全的两者 “分手”，所以对于普通使用者，并没有太大影响。

Docker+分布式数据库
数据库是每一个软件项目必须的一个部分，作为这样的一类底层基础软件，兼容性、通用性、易用度都是需要考虑的重点。非常遗憾的是，现在的操作系统以及数据库都没有完全的实现完全的通用。特别对于NoSQL数据库这样的分布式系统，需要部署在多台物理机时，对于通用性要求就更高了。
目前，像SequoiaDB已经实现了自动化的安装，大大提升了部署的效率，但是考虑到部署之后的配置以及不同环境下的调试问题，仍然可能会耗费不小的人力物力。所以基于刚刚提到的Docker的优点，作为一个通用的基础软件，NoSQL数据库的Docker化就成了必须。

一个简单的例子，你可以用docker把数据库的数据与数据库程序本身分离开：用一个container A作为数据存储，然后另一个container B运行数据库。当你想升级数据库时，用新的container C替换掉container B即可。
Docker+分布式数据库的结合，带来诸多的好处：
1) 部署简单，使用镜像部署非常简单，特别是对集群环境，使用Docker镜像的部署还可以再数据库上提前集成Hadoop、Spark等架构，真正实现“一步到位”。
2) 方便应用的更新，应用的更新只需要考虑制作一个新的镜像就可以与容器适配，无需重新再调整与底层的配置。数据和程序的分离，这样升级替换等等都不会影响到数据。
3) 操作简单方便，除了底层免除了复杂的与环境进行配置的工作，操作也更加方便，配置好的Docker镜像在部署时候只需要一条指令就可以了。
4) 开发、应用环境一致，Docker让数据库能做到 开发---测试---实施应用 三个阶段的环境是完全一致的。降低开发到应用过程中的工作量，开发出来就能保证实际应用环境上能同样的运行。
5) 系统稳定，因为Docker的隔离作用，将应用与OS独立开，这样能更好保证整个系统的稳定性。
6) 节省系统资源，系统只需要运行一个统一的环境就可以，不需要占用太多性能去支持运行环境本身，能将更多的系统资源投入到应用当中。
有了这些特性， Docker+数据库，将成为一个数据库发展的新方向，Docker这样的通用性和简单操作解决方案，大大提高了数据库使用的效率，帮助使用者节约了大量成本。
Docker是如今技术圈的新潮流，开发人员是最乐见于Docker的这种应用部署模式，因为应用的生命周期起始于开发人员的开发系统，经过开发，测试，压力测试，等过程，最终应用发布到生产系统，并可能在不同的生产系统中迁移。应用开发人员对此都会有切身的体会，任何微小的运行环境的错误都会导致应用出现问题，尤其在讲究快速敏捷的今天，应用模块，新的代码，新的配置，被快速的加入应用的环境中，可能还没等写入到文档，新特性就已经被推送到生产上了。作为一个新的技术，笔者也希望更多的产品能加强与Docker的结合，帮助产品更好的使用。
博文出处：http://segmentfault.com/a/1190000002930030