redis集群搭建

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

转( 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 的主从复制技术，当实现了多节点的 master-slave 后，我们也可以把它叫做集群，但我们今天要讲的集群主要是利用切片技术来组建的集群。 集群要实现的目的是要将不同的 key 分散放置到不同的 redis 节点，这里我们需要一个规则或者算法，通常的做法是获取 key 的哈希值，然后根据节点数来求模，但这种做法有其明显的弊端，当我们需要增加或减少一个节点时，会造成大量的 key 无法命中，这种比例是相当高的，所以就有人提出了一致性哈希的概念。 一致性哈希有四个重要特征： 均衡性：也有人把它定义为平衡性，是指哈希的结果能够尽可能分布到所有的节点中去，这样可以有效的利用每个节点上的资源。 单调性：对于单调性有很多翻译让我非常的不解，而我想要的是 当节点数量变化时哈希的结果应尽可能的 保护已分配的内容不会被重新分派到新的节点。 分散性和负载：这两个其实是差不多的意思，就是要求一致性哈希算法对 key 哈希应尽可能的避免重复。 但一致性哈希不是我们今天要介绍的重点，因为 Redis

一、Redis主从同步 1、主从复制概念 主从复制模型中，有多个redis节点。 其中，有且仅有一个为主节点Master。从节点Slave可以有多个。 只要网络连接正常，Master会一直将自己的数据更新同步给Slaves，保持主从同步。 2、特点 （1）主节点Master可读、可写. （2）从节点Slave只读。（read-only） 因此，主从模型可以提高读的能力，在一定程度上缓解了写的能力。因为能写仍然只有Master节点一个，可以将读的操作全部移交到从节点上，变相提高了写能力。 3、实验 实验环境： 本实验搭建主从同步，一主两备 server1虚拟机作主Redis缓存数据库: ip为：172.25.76.1 关闭防火墙及selinux server2虚拟机作备Redis缓存数据库: ip为：172.25.76.2 关闭防火墙及selinux server3虚拟机作备Redis缓存数据库: ip为：172.25.76.3 关闭防火墙及selinux 实验步骤： 主Redis（server1）上： yum install -y gcc -y #下载GNU编译器套件gcc tar zxf redis-5.0.3.tar.gz #解压redis安装包 cd redis-5.0.3 进入解压目录 make #编译 make install #安装 cd utils/ .

手动创建： 环境描述：一台机器启动六个节点，3个主节点，3个从节点。 安装： tar -zxvf redis-3.2.10.tar.gz mv redis-3.2.10 /usr/local/redis yum install gcc* tcl -y make && make test 修改配置文件： vi /usr/local/redis/redis.conf **要改的地方** daemonize yes port 7000 cluster-enabled yes cluster-config-file nodes-7000.conf . //这个编号最好是等于你的端口号 cluster-node-timeout 5000 mkdir /usr/local/cluster-test/ //同时复制配置文件，且修改端口及参数 **在/usr/local/cluster-test/下创建** mkdir 7000 mkdir 7001 mkdir 7002 mkdir 7003 mkdir 7004 mkdir 7005 启动服务： ./redis-server /usr/local/cluster-test/7000/redis.conf ./redis-server /usr/local/cluster-test/7001/redis.conf ./redis-server

docker 下redis集群配置： 1.获取官方redis镜像： docker pull redis: 2.编辑配置文件：配置文件可自行处理 vi redis1.cong bind 0.0.0.0 #绑定地址 protected-mode yes port 6392 #端口 tcp-backlog 511 timeout 0 tcp-keepalive 300 daemonize no #守护进程 supervised no pidfile /var/run/redis_6379.pid rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir ./ slave-serve-stale-data yes slave-read-only yes cluster-enabled yes #启用集群 cluster-config-file nodes-6379.conf # cluster-node-timeout 15000 #复制配置文件六分，修改端口 3#启用节点 docker的网络模式为net：使用宿主机的网络模式 --net=host docker run -d --name redis_136_6391 --net=host -v /home/wolfplus/docker/redis/redis.conf:

为什么需要集群？ 1、性能 Redis本身的QPS已经很高了，但是如果在一些并发量非常高的情况下，性能还是会受到影响。这个时候我们希望有更多的Redis服务来完成工作。 2、扩展 第二个是出于存储的考虑。因为Redis所有的数据都放在内存中，如果数据量大，很容易受到硬件的限制。升级硬件收效和成本比太低，所以我们需要有一种横向扩展的方法。 3、可用性 第三个是可用性和安全的问题。如果只有一个Redis服务，一旦服务宕机，那么所有的客户端都无法访问，会对业务造成很大的影响。另一个，如果硬件发生故障，而单机的数据无法恢复的话，带来的影响也是灾难性的。 可用性、数据安全、性能都可以通过搭建多个Reids服务实现。其中有一个是主节点（master），可以有多个从节点(slave)。主从之间通过数据同步，存储完全相同的数据。如果主节点发生故障，则把某个从节点改成主节点，访问新的主节点。 Redis主从复制（replication） 主从复制配置 例如一主多从,100是主节点，在每个slave节点的redis.conf配置文件增加一行 slaveof 192.168.1.100 6379 //在主从切换的时候，这个配置会被重写成： #GeneratedbyCONFIGREWRITE replicaof 192.168.1.100 6379 或者在启动服务时通过参数指定master节点： .

背景 作为中国最大的在线教育站点，目前沪江日志服务的用户包含网校，交易，金融，CCTalk 等多个部门的多个产品的日志搜索分析业务，每日产生的各类日志有好十几种，每天处理约10亿条（1TB）日志，热数据保留最近7天数据，冷数据永久保存。 为什么做日志系统 首先，什么是日志？ 日志就是程序产生的，遵循一定格式（通常包含时间戳）的文本数据 通常日志由服务器生成，输出到不同的文件中，一般会有系统日志、 应用日志、安全日志。这些日志分散地存储在不同的机器上。 通常当系统发生故障时，工程师需要登录到各个服务器上，使用 grep / sed / awk 等 Linux 脚本工具去日志里查找故障原因。在没有日志系统的情况下，首先需要定位处理请求的服务器，如果这台服务器部署了多个实例，则需要去每个应用实例的日志目录下去找日志文件。每个应用实例还会设置日志滚动策略（如：每天生成一个文件），还有日志压缩归档策略等。 这样一系列流程下来，对于我们排查故障以及及时找到故障原因，造成了比较大的麻烦。因此，如果我们能把这些日志集中管理，并提供集中检索功能，不仅可以提高诊断的效率，同时对系统情况有个全面的理解，避免事后救火的被动。 我认为，日志数据在以下几方面具有非常重要的作用： 数据查找 ：通过检索日志信息，定位相应的 bug ，找出解决方案 服务诊断 ：通过对日志信息进行统计、分析

参考文档： https://blog.csdn.net/lupengfei1009/article/details/88323561 注意：文中有两处需要自行处理： ①make地方，需要进入redis文件夹 ②执行redis-cli -p 7000时，如果命令报错，执行：sudo cp src/redis-cli /usr/local/bin/（将redis-cli拷贝到bin下，让redis-cli指令可以在任意目录下直接使用） 来源： oschina 链接： https://my.oschina.net/puguole/blog/3190901

前言 在 Redis Cluster集群 (一) 中了解了集群的相关概念，这一节我们将了解集群平台的搭建。 1. 简介 集群中至少应该有奇数个节点，所以搭建集群最少需要3台主机，同时每个节点至少有一个备份节点，所以下面最少要创建6台机器，才能完成Redis Cluster 集群（主节点，备份节点由redis-cluster集群确定） 真集群：六台服务器存在6个redis服务(这六台redis服务的主机号不同,端口号可以相同) 192.168.1.1.110: 6379 192.168.1.1.111: 6379 192.168.1.1.112: 6379 假集群: 一台服务器存在6个redis服务(这六台redis服务的主机号相同[因为使用同一台服务器]，端口号不相同) 192.168.1.111: 6379 192.168.1.111:6380 192.168.1.111:6382 2. 搭建集群环境 在这里由于我们自身设备有限，所以我们采用加集群进行搭建 [1] 创建Redis节点安装目录 mkdir /usr/local/redis_cluster //指定目录下 创建 redis_cluster [2] 在redis_cluster目录下，创建7001-7006 个文件夹下 mkdir 7001 7002 7003 7004 7005 7006 [3] 并将redis