codis

Redis操作是单线程的，使用连接池可以减少连接的创建，redis连接池有两种方式:Jedis(JedisPool) 和 Lettuce(LettucePool)。 Lettuce 和 Jedis 的定位都是Redis的client，所以他们当然可以直接连接redis server。在Lettuce和Jedis之外还有Redission ，Redisson：实现了分布式和可扩展的Java数据结构。 Redis 客户端Jedis和Lettuce的区别 Jedis Jedis在实现上是直接连接的Redis Server，如果在多线程环境下是非线程安全的。每个线程都去拿自己的 Jedis 实例，当连接数量增多时，资源消耗阶梯式增大，连接成本就较高了。这个时候只有使用连接池，为每个Jedis实例增加物理连接。 Lettuce Lettuce的连接是基于Netty的，Netty 是一个多线程、事件驱动的 I/O 框架。连接实例可以在多个线程间共享，当多线程使用同一连接实例时，是线程安全的。Lettuce连接实例（StatefulRedisConnection）可以在多个线程间并发访问，应为StatefulRedisConnection是线程安全的，所以一个连接实例（StatefulRedisConnection）就可以满足多线程环境下的并发访问，当然这个也是可伸缩的设计

【推荐阅读】微服务还能火多久？>>> 目录 一、内存统计 ​ 二、内存划分 ​ 三、内存消耗 四、缓冲内存 普通客户端缓冲区 slave客户端缓冲区 pubsub客户端缓冲区 一、内存统计 可以在 lua中自定义命令。 # Memory used_memory:33805895736 used_memory_human:31.48G used_memory_rss:42316582912 used_memory_rss_human:39.41G used_memory_peak:44346475840 used_memory_peak_human:41.30G total_system_memory:338519248896 total_system_memory_human:315.27G used_memory_lua:37888 used_memory_lua_human:37.00K maxmemory:200000000000 maxmemory_human:186.26G maxmemory_policy:volatile-lru mem_fragmentation_ratio:1.25 mem_allocator:jemalloc-4.0.3 二、内存划分 内存碎片是操作系统分配给的内存和实际使用的内存的差值。 例如 存了一个string类型的key。

【今日推荐】：为什么一到面试就懵逼！>>> 1.nignx限流部分用户参与秒杀活动 2.用户进入秒杀流程 3.用户是否分享app，才能参与秒杀 4.判断该用户是否有参与过该场秒杀记录，以及用户是否有曾经秒杀成功记录 5.记录用户正常参与该场秒杀活动，使用分布式锁尝试获取锁记录，获取不成功抛出异常。成功记录下面流程 6.秒杀商品是否秒杀完毕，使用redis自增长的做库存设定，查看库存数量。无，则已秒杀完毕 7.先到先得从redis的list 结构 的lpop中尝试弹出一个产品，是否成功，不成功证明已无秒杀商品 8.成功则使用redis商品场次与用户绑定， 记录用户参与该场秒杀结果，以及用户秒杀成功记录 9.用户秒杀成功记录通过kafka异步，存储到mysql数据库中 10.codis已做异步持久化处理 11.释放用户 参与过该场秒杀记 分布式锁 来源： oschina 链接： https://my.oschina.net/u/1017791/blog/3232580

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 月，跳不动了？>>> 环境介绍: 1:机器三台 ,IP/hostname 如下, hostname的设置很重要zookeeper / codis的通信都会用到,所以要配置好三台机器的hosts文件. 10.221.8. 220 机器的hostname为 Redis1 10.221.8 .221 机器的hostname为 Redis2 10.221.8 .222 机器的hostname为 Redis3 三台机器的/etc/hosts 文件添加如下解析 10.221.8. 220 Redis1 10.221.8.1. 221 Redis2 10.221.8.1. 222 Redis3 2: 三台机器的系统都是centos 6.5 已经安装基本服务. yum -y install gcc gcc-c++ make glibc glibc-devel glib2 glib2-devel patch autoconf automake（安装基本编译工具） yum -y install ntp wget unzip vixie-cron ntsysv openssh-clients sysstat irqbalance subversion（安装常用系统软件，按需） yum update -y （更新软件包） 3:使用三台机器做codis集群的服务部署如图: 服务的部署 第一步:

Codis集群的搭建与使用 一、简介 Codis是一个分布式的Redis解决方案，对于上层的应用来说，连接Codis Proxy和连接原生的Redis Server没有明显的区别（不支持的命令列表），上层应用可以像使用单机的Redis一样使用，Codis底层会处理请求的转发，不停机的数据迁移等工作，所有后边的一切事情，对于前面客户端来说是透明的，可以简单的认为后边连接是一个内存无限大的Redis服务。 Codis架构图： 以上我们可以看到codis-proxy是单个节点的，因为我们可以通过结合keepalived来实现高可用： codis-proxy 提供连接集群redis服务的入口 codis-redis-group 实现redis读写的水平扩展，高性能 codis-redis 实现redis实例服务，通过codis-ha实现服务的高可用 二、组件说明 codis-proxy : 是客户端连接的Redis代理服务，codis-proxy 本身实现了Redis协议，表现得和一个原生的Redis没什么区别（就像Twemproxy），对于一个业务来说，可以部署多个codis-proxy，codis-proxy本身是没状态的。 codis-config ：是Codis的管理工具，支持包括，添加/删除Redis节点，添加/删除Proxy节点，发起数据迁移等操作，codis

一.codis介绍 Codis是一个分布式Redis解决方案,对于上层的应用来说,连接到Codis Proxy和连接原生的RedisServer没有明显的区别,有部分命令不支持 Codis底层会处理请求的转发,不停机的数据迁移等工作,所有后边的一切事情,对于前面的客户端来说是透明的,可以简单的认为后边连接的是一个内存无限大的Redis服务. Codis由四部分组成 Codis-proxy:实现redis协议,由于本身是无状态的,因此可以部署很多个节点 Codis-config :是codis的管理工具,包括添加/删除redis节点添加删除proxy节点,发起数据迁移等操作,自带httpserver,支持管理后台方式管理配置 Codis-server :是codis维护的redis分支,基于2.8.21分支,加入了slot的支持和原子的数据迁移指令; codis-proxy和codis-config只能和这个版本的redis交互才能正常运行 Zookeeper,用于codis集群元数据的存储,维护codis集群节点 二.Codis优缺点 优点 对客户端透明,与codis交互方式和redis本身交互一样 支持在线数据迁移,迁移过程对客户端透明有简单的管理和监控界面 支持高可用,无论是redis数据存储还是代理节点 自动进行数据的均衡分配 最大支持1024个redis实例,存储容量海量

目的 在 Redis Codis 部署安装 的文章中，介绍了通过fe在web上搭建codis的基本步骤和方法，也介绍了codis-admin的相关说明，为了更好的熟悉codis-admin的使用，本文将使用codis-admin直接搭建 codis集群 （和fe进行相关的对比）。这样做的另一个目的是为实现自动化脚本部署的时候做相关的准备。 环境 和 Redis Codis 部署安装 中的环境一样，包括各个服务的IP和端口，以及安装方法。 机器 服务 端口 端口说明 依赖 192.168.163.131/132/133(Ubuntu 16.04) Codis 7021/7022 server端口:主/从（三台） GO 11080 proxy管理端口（三台） 18080 dashboard管理端口（一台） 10890 fe管理端口（一台） 10086 sentinel（三台） 192.168.163.131/132/133(Ubuntu 16.04) zookeeper 2181 zk客户端监听端口（三台） JDK 2888 zk内部通讯端口（三台） 3888 zk选举端口（三台） 开始 首先要保证ZooKeeper、Dashboard、Proxy、Server、Sentine、fe等都已经开启。根据 Redis Codis 部署安装 文章的安装和配置，进行codis相关组件的开启

【作业描述】 1.配置codis-ha 2.总结对比codis的集群方式和redis的cluster集群的优缺点 ================================================================================= 一、codis-ha的部署配置 ##codis-ha要独立于codis集群，单独配置，也是基于go环境的 1、go方式下载codis-ha: go get github.com/ngaut/codis-ha 2、进入codis-ha目录，执行go build命令： 3、启动codis-ha服务 codis-ha -codis-config="10.7.12.98:18087" -log-level="info" -productName='codis' & -codis-config参数，值为codis集群的管理控制台端口，也就是dashboard界面访问的IP：port -log-level参数，值为日志级别； -productName参数，值为产品名，可以在codis-proxy的配置文件里找到，如下： 或者通过dashboard管理界面查看： 4、测试codis-server的高可用性 （1）当前codis集群状态如下： （2）将redis8379进程杀掉，如下： codis-ha有如下日志输出：

转( 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的最终目标是提供数据库存储引擎不能提供的简单、高效、跨数据中心的数据复制功能