codis

 这节介绍Redis的集群模式  主从模式提供了读写分离的支持，Sentinel提供了高可用的保障，满足了读模式下的横向扩展，但主节点只有一个，集中式的写模式无法应对不断增长的写需求。  Redis 3.x 版本提供了Redis cluster 功能，服务端sharding使用槽作为分布式的解决方案。对于 2.x版本，则通过客户端API提供的客户端sharding方式，使用一致性哈希来实现数据分片。此外，twiter开源的 twemproxy 和豌豆荚的 codis ，则采用代理模式来实现。 1 服务端模式  对于客户端来说，整个集群被看做一个整体，客户端可以连接任意一个节点进行操作，就像操作单一Redis数据库一样。当客户端操作的key没有分配到该节点上时，会返回转向指令，指向正确的节点。 1.1 集群的建立  3.x 版本的Redis节点可以通过打开 clustrer-enabled 选项来开启服务器的集群模式，再通过 CLUSTER MEET <ip> <port> 命令连接其他节点。  新加入的节点B通过 CLUSTER MEET 命令同节点A建立连接后，节点A会通过 Gossip协议 将节点B的信息传播给集群中的其他节点，当其他节点发现新加入的节点B后也会主动同它建立连接。处于集群状态的节点同单机模式下的服务器实例没什么区别，只是只能使用 db 0 数据库

“高效运维最佳实践”是InfoQ在2015年推出的精品专栏，由触控科技运维总监萧田国撰写，InfoQ总编辑崔康策划。 前言 如开篇文章所言，高效运维包括管理的专业化和技术的专业化。前两篇我们主要在说些管理相关的内容，本篇说一下技术专业化。希望读者朋友们能适应这个转换，谢谢。 互联网早在几年前就已进入Web 2.0时代，对后台支撑能力的要求，提高了几十倍甚至几百倍。在这个演化过程中，缓存 系统 扮演了举足轻重的角色。 运维进化到今天，已经不是重复造轮子的时代。所以，我们在架构优化和 自 动化运维中，可以尽可能地选用优秀的开源产品，而不是自己完全从头再来（各种技术geek除外）。 本文主要讨论Redis集群相关技术及新发展，关于Redis运维等内容，以后另开主题讨论。 本文重点推荐Codis——豌豆荚开源的Redis分布式中间件（该项目于4个月前在GitHub开源，目前star已超过2100）。其和Twemproxy相比，有诸多激动人心的新特性，并支持从Twemproxy无缝迁移至Codis。 本文主要目录如下，对Redis比较了解的朋友，可跳过前两部分，直接欣赏Codis相关内容。 1. Redis常见集群技术 1.1 客户端分片 1.2 代理分片 1.3 Redis Cluster 2. Twemproxy及不足之处 3. Codis实践 3.1 体系架构 3.2 性能对比测试 3

1、 测试背景：由于业务需求，开发决定部署一个redis高可用方案codis，使用codis3.2版本。 2、 代码：非常简单的redis读写方法，读和写分开测。 3、基本架构：一台应用服务器（12核48G），单实例proxy（48核198G），三实例zk集群（48核198G），三组codis-server，每组各一个codis-server，具体配置信息如下。 4、开始压测，结果发现，TPS最高在1800左右，100并发时平均响应时间为53ms，200并发时平均响应时间为111ms，TPS基本不变，应用服务器CPU使用率在25%左右，codis和redis服务器压力非常小，典型的存在性能瓶颈的现象，开始定位瓶颈。 5、查看线程信息，发现有很多log4j的锁，基本定位问题，瓶颈是log4j引起的。也可以确定，log4j使用的是1.x版本，因为这个版本在多线程写日志时，存在同步锁，而Log4j 2使用了新一代的基于LMAX Disruptor的无锁异步日志系统。在多线程的程序中，异步日志系统吞吐量比Log4j 1.x高10倍，而时间延迟更低。这也是我们现在都用log4j2的原因。还只是猜测，实验一下吧。 6、更改log4j日志级别为OFF，就是不打印任何日志，然后重启。测试结果如下，上周五晚上测试结果读的TPS能到18000+，写能到20000+，瓶颈在应用服务器上

Codis介绍 Codis 是一种 Redis集群 的实现方案，与Redis社区的Redis cluster类似，基于slot的分片机制构建一个更大的Redis节点集群，对于连接到codis的Redis客户端来说, 除了部分不支持的命令外，与连接开源的 Redis Server 没有明显的区别, 客户端代码基本需要进行修改，Codis-proxy会根据访问的key进行slot的计算，然后转发请求到对应的Redis-server，对于客户端来说，中间的codis-proxy是不可见的，因此根据客户业务的需要，可以使用codis构建大规模的Redis 服务，或者仅仅是用于把请求分担多个Redis-server提高系统的吞吐量。 与业界著名的twproxy相比，除了支持Redis的转发，coids还支持不停机的数据迁移，使用户可以在容量或者吞吐量要求有变化时，轻松进行节点的增减，本文主要对codis的迁移原理进行分析，并提出一个可行的优化点。 本文是基于codis3.0版本。 （图片来自网络） Codis迁移实现原理 Codis-dashboard在启动时，运行了4个后台线程(goroutine)，包括后台redis状态同步、proxy状态同步、slot事件处理、sync事件处理，并提供了slot相关的RestFUL API进行slot与Redis-group归属关系的定义

pyhanlp用户自定义词典添加 实例说明 pyhanlp是python版封装的的HanLP，项目地址：https://github.com/hankcs/pyhanlp 经过测试，HanLP比nltk在中文分词和实体识别方面都更好用 . 如何向pyhanlp添加自定义的词典？以python 2.7.9为例： 1.安装pyhanlp：pip install pyhanlp 2.在字典路径下添加自定义的词典：CustomDictionary主词典文本路径是data/dictionary/custom/CustomDictionary.txt，用户可以在此增加自己的词语（不推荐）；也可以单独新建一个文本文件，通过配置文件；CustomDictionaryPath=data/dictionary/custom/CustomDictionary.txt; 我的词典.txt;来追加词典（推荐）。 具体绝对路径可用hanlp --version获取： #hanlp --version jar1.6.3:/usr/local/lib/python2.7/site-packages/pyhanlp/static/hanlp-1.6.3.jar data 1.6.2: /usr/local/lib/python2.7/site-packages/pyhanlp/static/data config:

Redis数据量日益增大，使用的公司越来越多，不仅用于做缓存，同时趋向于存储这一块，这样必促使集群的发展，各个公司也在收集适合自己的集群方案，目前行业用的比较多的是下面几种集群架构，大部分都是采用分片技术，保证单实例内存增大带来的一系列问题，下面所列出的codis方案目前正在不断测试过程中，测试过程没有展示出来，主要从以下几点出发。 测试架构 和性能 ： 　　1、keepalived+haproxy故障测试 　　2、Zookeeper集群节点测试 　　3、Codis-proxy集群节点测试 　　4、Codis-server集群节点测试 　　5、脚本写入大量测试数据并模拟数据迁移 　　6、性能测试 下面具体介绍codis和其他几大集群方案 集群方案： 　　1、 主从高可用（该方案就是单实例形式，只是为了保证数据的安全，对于用户数据少，业务的前期可以采用，目前我司缓存架构就是采用该方案） 　　2、 客户端分片（典型代表：Jedis。自主写分片算法，代码掌握在自己手中，可控性强，但是需要专业的开发运维人员维护，技术要求和维护成本高） 　　3、代理分片（典型代表：Twemproxy，redis集群没有正式推出之前官网推荐的方案，也是目前使用最多的） 　　4、 Redis cluster（3版本推出的集群方案，历时四年之多的开发） 　　5、 Codis集群（豌豆荚15年开源的解决方案

Redis简介 REmote DIctionary Server(Redis) Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。通常被称为数据结构服务器，值（value）可以是 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。支持主从模式的数据备份。拥有极高的读写性能，丰富的数据类型，原子性操作，还支持pub/sub，通知，key过期等特性。 与其他k-v存储的区别，redis有更为复杂的数据结构并且对他们提供原子性操作，redis运行在内存但支持持久化，持久化是以追加的方式产生的。 Redis是一个开源的高性能键值对数据库.它通过提供多种键值数据类型来适应不同场景下的存储需求,并且借助许多高层级的接口使其可以胜任,如缓存、队列系统的不同角色.将键值对数据类型存放在内存中的一个数据库。 单机安装 #挂载ISO操作系统光盘 [root@MySQLNODE02 /]# mount -t iso9660 /dev/cdrom /mnt/ #确认是否挂载成功 [root@MySQLNODE02 /]# df -h Filesystem Size Used Avail Use% Mounted on /dev

目的 在 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相关组件的开启

花擦节 闪电购拼团狂欢节 微信中打开：http://www.52shangou.com/buyer/pintuan/index.html Codis作者黄东旭细说分布式Redis架构设计和踩过的那些坑们 2015-07-06 黄东旭 高可用架构 此文根据【QCON高可用架构群】分享内容，由群内【编辑组】志愿整理，转发请注明出处。 黄东旭，Ping CAP CTO，开源项目Codis的co-author。之前在豌豆荚从事infrastructure相关的工作，现在在创业公司PingCAP，方向依然是分布式存储领域(NewSQL)。 本次分享的内容主要包括五个大部分： Redis、RedisCluster和Codis; 我们更爱一致性; Codis在生产环境中的使用的经验和坑们; 对于分布式数据库和分布式架构的一些看法; Q & A环节。   Codis是一个分布式Redis解决方案，与官方的纯P2P的模式不同，Codis采用的是Proxy-based的方案。今天我们介绍一下Codis及下一个大版本RebornDB的设计，同时会介绍一些Codis在实际应用场景中的tips。最后抛砖引玉，会介绍一下我对分布式存储的一些观点和看法，望各位首席们雅正。 一、 Redis，RedisCluster和Codis    Redis ：想必大家的架构中，Redis已经是一个必不可少的部件

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # Codis-Proxy # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 设置Codis产品名称/Auth。 product_name = " codis-demo " product_auth = " 123456 " 为客户端会话设置auth # 1。product_auth用于codis-dashboard之间的auth验证， # codis-proxy和codis-server。 # 2。session_auth与product_auth不同，它需要客户机 在处理任何其他命令之前发出AUTH 。 session_auth = " 123456 " 为admin(rpc)设置绑定地址，仅为tcp。 admin_addr = " 0.0.0.0:11080 " 为代理设置绑定地址，proto_type可以是“tcp”、“tcp4”、“tcp6”、“unix”或“unixpacket”。 proto_type =