Twemproxy

介绍 redis作为一款优秀的NoSQL代表软件，正变得越来越流行，虽然Redis很容易就可以启动并使用，但是要想在线上用好它却也并非易事。redis的高可用和可扩展无论是自带的Redis Sentinel还是Redis Cluster都要求客户端进行额外的支持，而目前基本上没有合适的客户端能够做这些事情，实际上客户端来做这些事情也并不合适，它会让维护变得特别困难。因此在客户端和redis服务端之间加一层代理成了一种理想的方案，代理屏蔽后端Redis实现细节向客户端提供redis服务，可以完美的解决Redis的高可用和扩展性问题，同时代理的引入也使得Redis维护变得更加简单。在本文所要介绍的代理predixy之前，已经有几款流行的redis代理，它们各具特色。接下来，我们就来比较以下代理： 代理 简介 详细功能对比 简单来说，predixy既支持Redis Sentinel也支持Redis Cluster 后端为Redis Sentinel监控的一组Redis，功能完全等同于原始Redis 后端为Redis Sentinel监控的多组Redis，则有部分功能受限 后端为Redis Cluster，功能完全等同于Redis Cluster 性能 作为redis代理，高性能是硬性要求，为了测试上面四款代理的性能接下来我们就来做个简单的评测，测试平台及各代理具体的版本信息如下：

3 月，跳不动了？>>> 本次分享的内容主要包括五个大部分： Redis、RedisCluster和Codis; 我们更爱一致性; Codis在生产环境中的使用的经验和坑们; 对于分布式数据库和分布式架构的一些看法; Q & A环节。   Codis是一个分布式Redis解决方案，与官方的纯P2P的模式不同，Codis采用的是Proxy-based的方案。今天我们介绍一下Codis及下一个大版本RebornDB的设计，同时会介绍一些Codis在实际应用场景中的tips。最后抛砖引玉，会介绍一下我对分布式存储的一些观点和看法，望各位首席们雅正。 一、 Redis，RedisCluster和Codis    Redis ：想必大家的架构中，Redis已经是一个必不可少的部件，丰富的数据结构和超高的性能以及简单的协议，让Redis能够很好的作为数据库的上游缓存层。但是我们会比较担心Redis的单点问题，单点Redis容量大小总受限于内存，在业务对性能要求比较高的情况下，理想情况下我们希望所有的数据都能在内存里面，不要打到数据库上，所以很自然的就会寻求其他方案。 比如，SSD将内存换成了磁盘，以换取更大的容量。更自然的想法是将Redis变成一个可以水平扩展的分布式缓存服务，在Codis之前，业界只有Twemproxy，但是Twemproxy本身是一个静态的分布式Redis方案，进行扩容

3 月，跳不动了？>>> 单机 redis最主要的适用场景:少量数据存储，高速读写访问，数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能。 分布式 随着用户量的增长，数据量随之增长，大型网站应用，热点数据量往往巨大，几十G上百G是很正常的事儿，这时候我们需要横向扩展，多台主机共同提供服务，既分布多个redis协同工作。大致有如下几种集群方案： 方案一：Redis官方集群方案Redis Cluster Redis Cluster由3.0版本正式推出，是一种服务器sharding技术，对客户端来说是完全透明的。 Redis Cluster中，Sharding采用slot(槽)的概念，一共分成16384个槽。对于每个进入Redis的键值对，根据key进行散列，分配到这16384个slot中的某一个中。使用的hash算法也比较简单，就是CRC16后16384取模。 Redis集群中的每个node(节点)负责分摊这16384个slot中的一部分，也就是说，每个slot都对应一个node负责处理。当动态添加或减少node节点时，需要将16384个槽做个再分配，槽中的键值也要迁移。当然，这一过程，在目前实现中，还处于半自动状态，需要人工介入。 Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效

Redis在豌豆荚的使用历程——单实例==》多实例，业务代码中做sharding==》单个Twemproxy==》多个Twemproxy==》Codis，豌豆荚自己开发的分布式Redis服务。在大规模的Redis使用过程中，他们发现Redis受限于多个方面：单机内存有限、带宽压力、单点问题、不能动态扩容以及磁盘损坏时的数据抢救。 Redis通常有3个使用途径：客户端静态分片，一致性哈希；通过Proxy分片，即Twemproxy；还有就是官方的Redis Cluster，但至今无一个新版本。随后刘奇更详细的分析了为什么不使用Twemproxy和Redis Cluster： Twemproxy：最大的痛点是无法平滑的扩容或者缩容，甚至修改配置都需要重启服务；其次，不可运维，甚至没有Dashboard。 Redis Cluster（官方）：无中心化设计，程序难以编写；代码有点吓人，clusterProcessPacket函数有426行，人脑难以处理所有的状态切换；迟迟没有正式版本，等了4年之久；目前还缺乏最佳实践，没有人编写Redis Cluster的若干条注意事项；整个系统高度耦合，升级困难。 虽然我们有众多的选择，比如 Tair 、 Couchbase 等，但是如果你需要更复杂和优秀的数据结构， Redis 可称为不二之选。基于这个原因，在 Redis 之上，豌豆荚设计了 Codis

转( http://www.jianshu.com/p/f8e968e57863 ) 一. 应用场景 redis 作为数据结构存储引擎，有着很多优点 高性能 单机引擎可以达到5-10W qps 数据结构全面，支持快速开发业务 string，list，set，sorted set， hashes 问题： 存储容量受限单机最大容量即为单机内存最大容量 单机数据的持久化依赖aof和rdb机制，如果机器整个down掉，服务不可用 二. redis集群选型 正是由于单机redis引擎有着这样的问题，所以，基本每个互联网公司都有自己的redis集群化方案。 在redis客户端lib中实现数据的分片并主从部署redis实例 优点：简单，性能损耗小 缺点：扩容方案复杂 集群化候选方案 1、NetFlix对Dynamo的开源通用实现Dynomite Dynomite是NetFlix对亚马逊分布式存储引擎Dynamo的一个开源通用实现，使用C/C++语言编写、以代理的方式实现的Redis缓存集群方案。Dynomite不仅能够将基于内存的Redis和Memcached打造成分布式数据库，还支持持久化的MySQL、BerkeleyDB、LevelDB等数据库，并具有简单、高效、支持跨数据中心的数据复制等优点。Dynomite的最终目标是提供数据库存储引擎不能提供的简单、高效、跨数据中心的数据复制功能

Redis是开源的免费的高效的以键值对类型的 NoSQL数据库; Redis自身优势: 1.支持的数据类型丰富; 2.因为使用的是内存,读写速度快; 3.原子性,redis中的操作都是单线程,但后期可能会出多线程; 4高可用,redis主从模式,哨兵,集群 5.可设置过期时间,消息订阅等 Redis支持的数据类型: String(字符串)、List(列表)、Set(无序去重集合)、Sorted Set(有序去重集合)、hash(哈希) Redis数据淘汰策略: noeviction 不允许淘汰数据,内存满返回错误信息; allkeys-lru 在所有数据列表中挑选调用最少的数据淘汰; volatile-lru 在已经过期的数据列表中淘汰使用最少的数据; allkeys-random 在所有数据列表中随机淘汰数据 volatile-random 在已经过期的数据列表中随机淘汰数据 volatile-ttl 在已经过期的数据列表中优先淘汰回收存活时间较短的数据; Redis的value值最大存储1个G, String类型最大存储512GB; Redis为了达到最快的读写速度,将数据都写入内存中,在通过异步的方式将数据持久化到磁盘中;这是Redis的优势; Redis的持久化方案: (默认)RDB AOF RDB: 是定期将数据快照保存在一个rbd文件中

分布式缓存集群方案特性使用场景（Memcache/Redis(Twemproxy/Codis/Redis-cluster)）优缺点对比及选型 分布式缓存特性： 1) 高性能:当传统数据库面临大规模数据访问时,磁盘I/O 往往成为性能瓶颈,从而导致过高的响应延迟.分布式缓存将高速内存作为数据对象的存储介质,数据以key/value 形式存储,理想情况下可以获得DRAM 级的读写性能; 2) 动态扩展性:支持弹性扩展,通过动态增加或减少节点应对变化的数据访问负载,提供可预测的性能与扩展性;同时,最大限度地提高资源利用率; 3) 高可用性:可用性包含数据可用性与服务可用性两方面.基于冗余机制实现高可用性,无单点失效(single point of failure),支持故障的自动发现,透明地实施故障切换,不会因服务器故障而导致缓存服务中断或数据丢失.动态扩展时自动均衡数据分区,同时保障缓存服务持续可用; 4) 易用性:提供单一的数据与管理视图;API 接口简单,且与拓扑结构无关;动态扩展或失效恢复时无需人工配置;自动选取备份节点;多数缓存系统提供了图形化的管理控制台,便于统一维护; 5) 分布式代码执行(distributed code execution):将任务代码转移到各数据节点并行执行,客户端聚合返回结果,从而有效避免了缓存数据的移动与传输.最新的Java 数据网格规范JSR

线上PHP程序动不动就报PHP Fatal error: Uncaught RedisException: read error on connection错误，就是连接Redis在那么1秒钟有问题，我们的架构是： PHP程序—>twemproxy代理—>Redis实例（5个节点） PHP-FPM的超时时间是1s钟，也就是说如果PHP程序执行超过1s钟就会中断，另外由于Redis是单线程的，所以如果一个请求的时间太久就会造成Redis假死状态，接收不了其他请求，继而就会造成PHP程序连接报错。 首先接收到错误日志是在ELK上面，如下图： 看一下报错的时间和报错数量，报错的数据有3000多个，而报错时间都在14:41分。 然后看了twemproxy的日志。 可以看出执行时间都是1s多，肯定是不正常的，正常情况下一个Redis Get请求大概在20ms左右。同时可以看出twemproxy报错的后端服务器都是同一个（一共有5个后端）。 然后去172.18.129.135:6546这个实例上面查看慢日志。 127.0.0.1:6546> SLOWLOG get 1 1) 1) (integer) 50 2) (integer) 1470724891 #执行时间戳,转换为正常时间为2016/8/9 14:41:31; 3) (integer) 1761020 #执行时间,微秒; 4) 1)

负载均衡的几种常用方案 总结下负载均衡的常用方案及适用场景； Round Robin 轮询调度 以轮询的方式依次请求调度不同的服务器； 实现时，一般为服务器带上权重；这样有两个好处： 针对服务器的性能差异可分配不同的负载； 当需要将某个结点剔除时，只需要将其权重设置为0即可； 优点：实现简单、高效；易水平扩展； 缺点：请求到目的结点的不确定，造成其无法适用于有写的场景（缓存，数据库写） 应用场景：数据库或应用服务层中只有读的场景； 随机方式 请求随机分布到各个结点；在数据足够大的场景能达到一个均衡分布； 优点：实现简单、易水平扩展； 缺点：同Round Robin，无法用于有写的场景； 应用场景：数据库负载均衡，也是只有读的场景； 哈希方式 根据key来计算需要落在的结点上，可以保证一个同一个键一定落在相同的服务器上； 优点：相同key一定落在同一个结点上，这样就可用于有写有读的缓存场景； 缺点：在某个结点故障后，会导致哈希键重新分布，造成命中率大幅度下降； 解决：一致性哈希 or 使用keepalived保证任何一个结点的高可用性，故障后会有其它结点顶上来； 应用场景：缓存，有读有写； 一致性哈希 在服务器一个结点出现故障时，受影响的只有这个结点上的key，最大程度的保证命中率； 如twemproxy中的ketama方案； 生产实现中还可以规划指定子key哈希

1、什么是Redis？ Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。 Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据结构，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一 个功能加强版的memcached来用。 Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。 2、Redis相比memcached有哪些优势？ (1) memcached所有的值均是简单的字符串，redis作为其替代者， 支持更为丰富的数据类型 (2) redis的速度比memcached快很多 (3) redis可以持久化其数据 3、Redis支持哪几种数据类型