分类 Cache 下的文章

Redis客户端输出缓冲区限制调整

Redis为了解决输出缓冲区消息大量堆积的隐患,设置了一些保护机制,主要采用两种限制措施:
大小限制,当某一客户端缓冲区超过设定值后直接关闭连接;
持续性限制,当某一客户端缓冲区持续一段时间占用过大空间时关闭连接。
通过CONFIG GET *查看,可以找到客户端输出缓冲区的默认配置:

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

对于普通客户端来说,限制为0,也就是不限制。因为普通客户端通常采用阻塞式的消息应答模式,何谓阻塞式呢?如:发送请求,等待返回,再发送请求,再等待返回。这种模式下,通常不会导致Redis服务器输出缓冲区的堆积膨胀;
对于Pub/Sub客户端(也就是发布/订阅模式),大小限制是8M,当输出缓冲区超过8M时,会关闭连接。持续性限制是,当客户端缓冲区大小持续60秒超过2M,则关闭客户端连接;
对于slave客户端来说,大小限制是256M,持续性限制是当客户端缓冲区大小持续60秒超过64M,则关闭客户端连接。






---阅读剩余部分---

Keepalived 2.0.9 + Redis5.0部署redis主从高可用

项目需要部署搭建redis主从高可用环境,对外使用VIP提供服务,以下是实现步骤:
Keepalived 实现VRRP(虚拟路由冗余)协议,从路由级别实现VIP切换,可以完全避免类似heartbeat脑裂问题,可以很好的实现主从、主备、互备方案。
实现切换逻辑如下:A和B两台机器

1)A 、B机器依次启动,A机作为主、B机为从。
2)主A挂掉,B接管业务并作为主。
3)A机起来,作为从SLAVEOF B。
4)B机挂掉,A机再切回主。

在Keepalived 有两个角色:Master(一个)、Backup(多个),如果设置一个为Master,但Master挂了后再起来,必然再次业务又一次切换,这对于有状态服务是不可接受的。解决方案就是两台机器都设置为Backup,而且优先级高的Backup设置为nopreemt 不抢占主。
服务器环境:




---阅读剩余部分---

WARNING: The TCP backlog setting of 511 ......报错解决

安装好redis后,如果系统没有调优,启动的时候会报错:

WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
警告:TCP backlog的值设定是511,这是无法启动的,因为/proc/sys/net/core/somaxconn的设定值是128,比你的511要低。

解决方法:

echo 2048 > /proc/sys/net/core/somaxconn
echo 'net.core.somaxconn=1024' >> /etc/sysctl.conf
sysctl -p

在重启redis服务即可,log里面无报错了·
net.core.somaxconn参数说明:

net.core.somaxconn是linux中的一个kernel参数,表示socket监听(listen)的backlog上限。
backlog是socket的监听队列,当一个请求(request)尚未被处理或建立时,他会进入backlog。
而socket server可以一次性处理backlog中的所有请求,处理后的请求不再位于监听队列中。
当server处理请求较慢,以至于监听队列被填满后,新来的请求会被拒绝。
所以说net.core.somaxconn限制了接收新 TCP 连接侦听队列的大小。
对于一个经常处理新连接的高负载 web服务环境来说,默认的 128 太小了。
大多数环境这个值建议增加到 2048 或者更多。

Docker环境下安装部署Redis5.0挂载外部配置和数据

作为一种新兴的虚拟化方式,Docker 跟传统的虚拟化方式相比具有众多的优势。
docker-redis.png
本文记录docker下安装部署redis5.0的过程:
os版本centos7.5
先更新 yum 软件管理器,然后再安装 Docker

[root@localhost /] yum -y update
[root@localhost /] yum install -y docker

验证安装,查看 Docker 版本信息

[root@localhost /] docker -v
Docker version 1.13.1, build 8633870/1.13.1
You have new mail in /var/spool/mail/root

启动、停止、重启docker服务、加入开机启动

systemctl start docker
systemctl stop docker
systemctl restart docker
systemctl enable docker

安装redis5.0镜像

[root@sso-nginx-b ~]# systemctl start docker
[root@sso-nginx-b ~]# docker pull redis:5.0
Trying to pull repository docker.io/library/redis ... 
5.0: Pulling from docker.io/library/redis
f17d81b4b692: Pull complete 
b32474098757: Pull complete 
8980cabe8bc2: Pull complete 
2719bdbf9516: Pull complete 
f306130d78e3: Pull complete 
3e09204f8155: Pull complete 
Digest: sha256:481678b4b5ea1cb4e8d38ed6677b2da9b9e057cf7e1b6c988ba96651c6f6eff3
Status: Downloaded newer image for docker.io/redis:5.0

创建redis运行目录及文件

mkdir -p /data/docker/redis
touch /data/docker/redis/redis.conf

redis.conf文件内容如下:

bind 172.17.0.2 127.0.0.1
#bind 0.0.0.0
protected-mode yes
port 6380
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize no   #如果daemonize yes无法启动容器
supervised no
pidfile /data/docker/redis/6380.pid
loglevel notice
logfile "6380.log"
databases 16
always-show-logo yes
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir ./
slave-serve-stale-data yes
slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
slave-priority 100
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
slave-lazy-flush no
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
aof-use-rdb-preamble no
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes

创建redis实例:

docker run -d --privileged=true --restart=always -p 6380:6380 -v /data/docker/redis/redis.conf:/etc/redis/redis.conf -v /data/docker/redis:/data --name redistest1 redis:5.0 redis-server /etc/redis/redis.conf --appendonly yes

实例说明如下:

--privileged=true 容器内的root拥有真正root权限,否则容器内root只是外部普通用户权限
--restart=always 开机启动容器
-p 6380:6380 映射宿主机6380端口到docker端口6380
-v /data/docker/redis/redis.conf:/etc/redis/redis.conf   映射配置文件
-v /data/docker/redis:/data  映射数据目录地址
--name redistest1 redis:5.0 redis-server /etc/redis/redis.conf   #docker名字 redis实例名 配置文件
--appendonly yes:开启持久化

查看redistest1容器的IP地址:

docker inspect redistest1 | grep -i address
            "LinkLocalIPv6Address": "",
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "GlobalIPv6Address": "",
            "IPAddress": "172.17.0.2",
            "MacAddress": "02:42:ac:11:00:02",
                    "IPAddress": "172.17.0.2",
                    "GlobalIPv6Address": "",
                    "MacAddress": "02:42:ac:11:00:02"

将/data/docker/redis/redis.conf里面的bind地址修改为

bind 172.17.0.2 127.0.0.1

重启redistest1容器:

docker restart redistest1

进入redis控制台:

redis-cli -h 172.17.0.2 -p 6380  #172.17.0.2是redistest1容器的IP地址,也可以用宿主机IP地址进入

启动另外一个redis实例:

docker run -d --privileged=true --restart=always -p 6381:6381 -v /data/docker/redis-6381/redis.conf:/etc/redis/redis.conf -v /data/docker/redis-6381:/data --name redistest2 redis:5.0 redis-server /etc/redis/redis.conf --appendonly yes

至此,docker上安装部署redis完毕.

kafka报错INFO Reconnect due to socket error: java.nio.channels.ClosedChannelException (kafka.consumer.SimpleConsumer

kafka安装启动以后server.log一直报INFO Reconnect due to socket error: java.nio.channels.ClosedChannelException (kafka.consumer.SimpleConsumer错误信息,如下

[2018-06-19 09:43:29,783] INFO Reconnect due to socket error: java.nio.channels.ClosedChannelException (kafka.consumer.SimpleConsumer)
[2018-06-19 09:43:29,783] WARN [ReplicaFetcherThread-0-1], Error in fetch Name: FetchRequest; Version: 0; CorrelationId: 518500; ClientId: ReplicaFetcherThread-0-1; ReplicaId: 2; MaxWait: 500 ms; MinBytes: 1 bytes; RequestInfo: [a6,5] -> PartitionFetchInfo(0,1048576),[a6,3] -> PartitionFetchInfo(0,1048576),[a6,7] -> PartitionFetchInfo(0,1048576),[a6,1] -> PartitionFetchInfo(0,1048576),[a6,9] -> PartitionFetchInfo(0,1048576). Possible cause: java.nio.channels.ClosedChannelException (kafka.server.ReplicaFetcherThread)
[2018-06-19 09:43:29,783] INFO Reconnect due to socket error: java.nio.channels.ClosedChannelException (kafka.consumer.SimpleConsumer)
[2018-06-19 09:43:29,783] WARN [ReplicaFetcherThread-0-1], Error in fetch Name: FetchRequest; Version: 0; CorrelationId: 518501; ClientId: ReplicaFetcherThread-0-1; ReplicaId: 2; MaxWait: 500 ms; MinBytes: 1 bytes; RequestInfo: [a6,5] -> PartitionFetchInfo(0,1048576),[a6,3] -> PartitionFetchInfo(0,1048576),[a6,7] -> PartitionFetchInfo(0,1048576),[a6,1] -> PartitionFetchInfo(0,1048576),[a6,9] -> PartitionFetchInfo(0,1048576). Possible cause: java.nio.channels.ClosedChannelException (kafka.server.ReplicaFetcherThread)
[2018-06-19 09:43:29,783] INFO Reconnect due to socket error: java.nio.channels.ClosedChannelException (kafka.consumer.SimpleConsumer)
[2018-06-19 09:43:29,783] WARN [ReplicaFetcherThread-0-1], Error in fetch Name: FetchRequest; Version: 0; CorrelationId: 518502; ClientId: ReplicaFetcherThread-0-1; ReplicaId: 2; MaxWait: 500 ms; MinBytes: 1 bytes; RequestInfo: [a6,5] -> PartitionFetchInfo(0,1048576),[a6,3] -> PartitionFetchInfo(0,1048576),[a6,7] -> PartitionFetchInfo(0,1048576),[a6,1] -> PartitionFetchInfo(0,1048576),[a6,9] -> PartitionFetchInfo(0,1048576). Possible cause: java.nio.channels.ClosedChannelException (kafka.server.ReplicaFetcherThread)

原因是/etc/hosts文件里面没有添加kafka集群的机器名,

10.0.28.51 huafadb1
10.0.28.52 huafadb2

10.0.28.51    k1
10.0.28.52    k2
10.0.28.51    k3
                
10.0.28.51    z1
10.0.28.52    z2
10.0.28.51    z3

一般容易忘记前面两个主机名,huafadb1和huafadb2对应的IP,每个集群机器都添加,添加完成以后重启kafka服务即可解决。

Redis高可用方案之sentinel(哨兵集群)

Redis哨兵为Redis提供了高可用性。实际上这意味着你可以使用哨兵模式创建一个可以不用人为干预而应对各种故障的Redis部署。

监控:哨兵不断的检查master和slave是否正常的运行。
通知:当监控的某台Redis实例发生问题时,可以通过API通知系统管理员和其他的应用程序。
自动故障转移:如果一个master不正常运行了,哨兵可以启动一个故障转移进程,将一个slave升级成为master,其他的slave被重新配置使用新的master,并且应用程序使用Redis服务端通知的新地址。
配置提供者:哨兵作为Redis客户端发现的权威来源:客户端连接到哨兵请求当前可靠的master的地址。如果发生故障,哨兵将报告新地址。

Redis哨兵是一个分布式系统:
哨兵自身被设计成和多个哨兵进程一起合作运行。有多个哨兵进程合作的好处有:

当多个哨兵对一个master不再可用达成一致时执行故障检测。这会降低错误判断的概率。
即使在不是所有的哨兵都工作时哨兵也会工作,使系统健壮的抵抗故障。毕竟在故障系统里单点故障没有什么意义。
Redis的哨兵、Redis实例(master和slave)、和客户端是一个有特种功能的大型分布式系统。

部署哨兵之前需要了解的基本事情:

一个健壮的部署至少需要三个哨兵实例。
三个哨兵实例应该放置在客户使用独立方式确认故障的计算机或虚拟机中。例如不同的物理机或不同可用区域的虚拟机。
sentinel + Redis实例不保证在故障期间保留确认的写入,因为Redis使用异步复制。然而有方式部署哨兵使丢失数据限制在特定时刻,虽然有更安全的方式部署它。
你的客户端要支持哨兵,流行的客户端都支持哨兵,但不是全部。
没有HA设置是安全的,如果你不经常的在开发环境测试,在生产环境他们会更好。你可能会有一个明显的错误配置只是当太晚的时候。
Sentinel,Docker,或者其他形式的网络地址交换或端口映射需要加倍小心:Docker执行端口重新映射,破坏Sentinel自动发现其他的哨兵进程和master的slave列表。

机器信息:
192.168.121.40 Master
192.168.121.41 Slave1
192.168.121.42 Slave2
Master(192.168.121.40)机器配置如下:
redis.conf

cat redis.conf | grep -v "#"

bind 127.0.0.1 192.168.121.40

protected-mode yes

port 6879

tcp-backlog 511

timeout 0

tcp-keepalive 300

daemonize yes

supervised no

pidfile "/usr/local/redis-4.0.10_6879/redis_6879.pid"

loglevel notice

logfile "/usr/local/redis-4.0.10_6879/redis_6879.log"

databases 16

always-show-logo yes
save 900 1
save 300 10
save 60 10000

stop-writes-on-bgsave-error yes

rdbcompression yes

rdbchecksum yes

dbfilename "dump.rdb"

dir "/usr/local/redis-4.0.10_6879"

slave-serve-stale-data yes

slave-read-only yes

repl-diskless-sync no

repl-diskless-sync-delay 5

repl-disable-tcp-nodelay no

slave-priority 100

lazyfree-lazy-eviction no

lazyfree-lazy-expire no

lazyfree-lazy-server-del no

slave-lazy-flush no

appendonly yes

appendfilename "appendonly.aof"

appendfsync everysec

no-appendfsync-on-rewrite no

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

aof-load-truncated yes

aof-use-rdb-preamble no

lua-time-limit 5000

cluster-node-timeout 15000

slowlog-log-slower-than 10000

slowlog-max-len 128

latency-monitor-threshold 0

notify-keyspace-events ""

hash-max-ziplist-entries 512

hash-max-ziplist-value 64

list-max-ziplist-size -2

list-compress-depth 0

set-max-intset-entries 512

zset-max-ziplist-entries 128

zset-max-ziplist-value 64

hll-sparse-max-bytes 3000

activerehashing yes

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

hz 10

aof-rewrite-incremental-fsync yes

slaveof 192.168.121.41 6879

Slave1和Slave2配置相同,只是bind处需要把IP改成41和42
Master的sentinel.conf哨兵配置文件:
Redis源码发布包包含一个sentinel.conf的文件,Master(192.168.121.40)机器配置如下:

cat sentinel.conf 
port 26879  
#1表示在sentinel集群中只要有两个节点检测到redis主节点出故障就进行切换,单sentinel节点无效(自己测试发现的)  
#如果3s内mymaster无响应,则认为mymaster宕机了  
#如果10秒后,mysater仍没活过来,则启动failover  
sentinel monitor mymaster 192.168.121.40 6879 1  
sentinel down-after-milliseconds mymaster 3000  
sentinel failover-timeout mymaster 10000  
daemonize yes  
#指定工作目录  
dir "/data/redis/sentinel-work"  
protected-mode no  
logfile "/data/redis/sentinellog/sentinel.log"  
# Generated by CONFIG REWRITE

Slave(192.168.121.41-42)机器配置同上
注意:以上配置中不存在的文件路径需要手动创建。哨兵可配置多个,最好是最少3个节点,配置相同。

启动集群
启动192.168.121.40-41--42各机器Redis节点命令如下:

/usr/local/redis-4.0.10_6879/src/redis-server /usr/local/redis-4.0.10_6879/redis.conf 

启动各Redis哨兵节点命令如下:

/usr/local/redis-4.0.10_6879/src/redis-sentinel /usr/local/redis-4.0.10_6879/sentinel.conf 

三台都启动完成以后登陆 列出Slave的信息

[root@wgq_idc_cache_3_40 redis-4.0.10_6879]# /usr/local/redis-4.0.10_6879/src/redis-cli -p 6879
127.0.0.1:6879> info Replication
# Replication
role:slave
master_host:192.168.121.41
master_port:6879
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:2049886
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:50eb71744c1aacc84bd865ff3af7ee1902395634
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:2049886
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1001311
repl_backlog_histlen:1048576

查看启动sentinel.log

cat sentinel.log 
4453:X 15 Jun 17:09:41.774 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
4453:X 15 Jun 17:09:41.774 # Redis version=4.0.10, bits=64, commit=00000000, modified=0, pid=4453, just started
4453:X 15 Jun 17:09:41.774 # Configuration loaded
4454:X 15 Jun 17:09:41.779 * Running mode=sentinel, port=26879.
4454:X 15 Jun 17:09:41.779 # Sentinel ID is 5092d7a7096ec024a1d15e0fc903f7c289d4bd8a
4454:X 15 Jun 17:09:41.779 # +monitor master mymaster 192.168.121.40 6879 quorum 1
4454:X 15 Jun 17:12:47.369 # +sdown master mymaster 192.168.121.40 6879
4454:X 15 Jun 17:12:47.369 # +odown master mymaster 192.168.121.40 6879 #quorum 1/1
4454:X 15 Jun 17:12:47.369 # +new-epoch 1
4454:X 15 Jun 17:12:47.369 # +try-failover master mymaster 192.168.121.40 6879
4454:X 15 Jun 17:12:47.370 # +vote-for-leader 5092d7a7096ec024a1d15e0fc903f7c289d4bd8a 1
4454:X 15 Jun 17:12:47.371 # +elected-leader master mymaster 192.168.121.40 6879
4454:X 15 Jun 17:12:47.371 # +failover-state-select-slave master mymaster 192.168.121.40 6879
4454:X 15 Jun 17:12:47.442 # +selected-slave slave 192.168.121.42:6879 192.168.121.42 6879 @ mymaster 192.168.121.40 6879
4454:X 15 Jun 17:12:47.442 * +failover-state-send-slaveof-noone slave 192.168.121.42:6879 192.168.121.42 6879 @ mymaster 192.168.121.40 6879
4454:X 15 Jun 17:12:47.572 * +failover-state-wait-promotion slave 192.168.121.42:6879 192.168.121.42 6879 @ mymaster 192.168.121.40 6879
4454:X 15 Jun 17:12:48.401 # +promoted-slave slave 192.168.121.42:6879 192.168.121.42 6879 @ mymaster 192.168.121.40 6879

到这里我们已经完成了sentinel集群的搭建;
如果启动有此警告信息:

WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

方法1: 临时设置生效:

sysctl -w net.core.somaxconn = 65535
sysctl -w vm.overcommit_memory = 1

方法2: 永久生效: 修改/etc/sysctl.conf文件,增加一行

net.core.somaxconn = 65535
vm.overcommit_memory = 1

然后执行命令

sysctl -p

参考:http://redis.majunwei.com/topics/sentinel.html

Kafka主要配置文件参数详解

官方文档地址:http://kafka.apache.org/documentation.html

############################# System #############################
#唯一标识在集群中的ID,要求是正数。
broker.id=0
#服务端口,默认9092
port=9092
#监听地址,不设为所有地址
host.name=debugo01

# 处理网络请求的最大线程数
num.network.threads=2
# 处理磁盘I/O的线程数
num.io.threads=8
# 一些后台线程数
background.threads = 4
# 等待IO线程处理的请求队列最大数
queued.max.requests = 500

#  socket的发送缓冲区(SO_SNDBUF)
socket.send.buffer.bytes=1048576
# socket的接收缓冲区 (SO_RCVBUF) 
socket.receive.buffer.bytes=1048576
# socket请求的最大字节数。为了防止内存溢出,message.max.bytes必然要小于
socket.request.max.bytes = 104857600

############################# Topic #############################
# 每个topic的分区个数,更多的partition会产生更多的segment file
num.partitions=2
# 是否允许自动创建topic ,若是false,就需要通过命令创建topic
auto.create.topics.enable =true
# 一个topic ,默认分区的replication个数 ,不能大于集群中broker的个数。
default.replication.factor =1
# 消息体的最大大小,单位是字节
message.max.bytes = 1000000

############################# ZooKeeper #############################
# Zookeeper quorum设置。如果有多个使用逗号分割
zookeeper.connect=debugo01:2181,debugo02,debugo03
# 连接zk的超时时间
zookeeper.connection.timeout.ms=1000000
# ZooKeeper集群中leader和follower之间的同步实际
zookeeper.sync.time.ms = 2000

############################# Log #############################
#日志存放目录,多个目录使用逗号分割
log.dirs=/var/log/kafka

# 当达到下面的消息数量时,会将数据flush到日志文件中。默认10000
#log.flush.interval.messages=10000
# 当达到下面的时间(ms)时,执行一次强制的flush操作。interval.ms和interval.messages无论哪个达到,都会flush。默认3000ms
#log.flush.interval.ms=1000
# 检查是否需要将日志flush的时间间隔
log.flush.scheduler.interval.ms = 3000

# 日志清理策略(delete|compact)
log.cleanup.policy = delete
# 日志保存时间 (hours|minutes),默认为7天(168小时)。超过这个时间会根据policy处理数据。bytes和minutes无论哪个先达到都会触发。
log.retention.hours=168
# 日志数据存储的最大字节数。超过这个时间会根据policy处理数据。
#log.retention.bytes=1073741824

# 控制日志segment文件的大小,超出该大小则追加到一个新的日志segment文件中(-1表示没有限制)
log.segment.bytes=536870912
# 当达到下面时间,会强制新建一个segment
log.roll.hours = 24*7
# 日志片段文件的检查周期,查看它们是否达到了删除策略的设置(log.retention.hours或log.retention.bytes)
log.retention.check.interval.ms=60000

# 是否开启压缩
log.cleaner.enable=false
# 对于压缩的日志保留的最长时间
log.cleaner.delete.retention.ms = 1 day

# 对于segment日志的索引文件大小限制
log.index.size.max.bytes = 10 * 1024 * 1024
#y索引计算的一个缓冲区,一般不需要设置。
log.index.interval.bytes = 4096

############################# replica #############################
# partition management controller 与replicas之间通讯的超时时间
controller.socket.timeout.ms = 30000
# controller-to-broker-channels消息队列的尺寸大小
controller.message.queue.size=10
# replicas响应leader的最长等待时间,若是超过这个时间,就将replicas排除在管理之外
replica.lag.time.max.ms = 10000
# 是否允许控制器关闭broker ,若是设置为true,会关闭所有在这个broker上的leader,并转移到其他broker
controlled.shutdown.enable = false
# 控制器关闭的尝试次数
controlled.shutdown.max.retries = 3
# 每次关闭尝试的时间间隔
controlled.shutdown.retry.backoff.ms = 5000

# 如果relicas落后太多,将会认为此partition relicas已经失效。而一般情况下,因为网络延迟等原因,总会导致replicas中消息同步滞后。如果消息严重滞后,leader将认为此relicas网络延迟较大或者消息吞吐能力有限。在broker数量较少,或者网络不足的环境中,建议提高此值.
replica.lag.max.messages = 4000
#leader与relicas的socket超时时间
replica.socket.timeout.ms= 30 * 1000
# leader复制的socket缓存大小
replica.socket.receive.buffer.bytes=64 * 1024
# replicas每次获取数据的最大字节数
replica.fetch.max.bytes = 1024 * 1024
# replicas同leader之间通信的最大等待时间,失败了会重试
replica.fetch.wait.max.ms = 500
# 每一个fetch操作的最小数据尺寸,如果leader中尚未同步的数据不足此值,将会等待直到数据达到这个大小
replica.fetch.min.bytes =1
# leader中进行复制的线程数,增大这个数值会增加relipca的IO
num.replica.fetchers = 1
# 每个replica将最高水位进行flush的时间间隔
replica.high.watermark.checkpoint.interval.ms = 5000
 
# 是否自动平衡broker之间的分配策略
auto.leader.rebalance.enable = false
# leader的不平衡比例,若是超过这个数值,会对分区进行重新的平衡
leader.imbalance.per.broker.percentage = 10
# 检查leader是否不平衡的时间间隔
leader.imbalance.check.interval.seconds = 300
# 客户端保留offset信息的最大空间大小
offset.metadata.max.bytes = 1024

#############################Consumer #############################
# Consumer端核心的配置是group.id、zookeeper.connect
# 决定该Consumer归属的唯一组ID,By setting the same group id multiple processes indicate that they are all part of the same consumer group.
group.id
# 消费者的ID,若是没有设置的话,会自增
consumer.id
# 一个用于跟踪调查的ID ,最好同group.id相同
client.id = <group_id>
 
# 对于zookeeper集群的指定,必须和broker使用同样的zk配置
zookeeper.connect=debugo01:2182,debugo02:2182,debugo03:2182
# zookeeper的心跳超时时间,查过这个时间就认为是无效的消费者
zookeeper.session.timeout.ms = 6000
# zookeeper的等待连接时间
zookeeper.connection.timeout.ms = 6000
# zookeeper的follower同leader的同步时间
zookeeper.sync.time.ms = 2000
# 当zookeeper中没有初始的offset时,或者超出offset上限时的处理方式 。
# smallest :重置为最小值 
# largest:重置为最大值 
# anything else:抛出异常给consumer
auto.offset.reset = largest

# socket的超时时间,实际的超时时间为max.fetch.wait + socket.timeout.ms.
socket.timeout.ms= 30 * 1000
# socket的接收缓存空间大小
socket.receive.buffer.bytes=64 * 1024
#从每个分区fetch的消息大小限制
fetch.message.max.bytes = 1024 * 1024
 
# true时,Consumer会在消费消息后将offset同步到zookeeper,这样当Consumer失败后,新的consumer就能从zookeeper获取最新的offset
auto.commit.enable = true
# 自动提交的时间间隔
auto.commit.interval.ms = 60 * 1000
 
# 用于消费的最大数量的消息块缓冲大小,每个块可以等同于fetch.message.max.bytes中数值
queued.max.message.chunks = 10

# 当有新的consumer加入到group时,将尝试reblance,将partitions的消费端迁移到新的consumer中, 该设置是尝试的次数
rebalance.max.retries = 4
# 每次reblance的时间间隔
rebalance.backoff.ms = 2000
# 每次重新选举leader的时间
refresh.leader.backoff.ms
 
# server发送到消费端的最小数据,若是不满足这个数值则会等待直到满足指定大小。默认为1表示立即接收。
fetch.min.bytes = 1
# 若是不满足fetch.min.bytes时,等待消费端请求的最长等待时间
fetch.wait.max.ms = 100
# 如果指定时间内没有新消息可用于消费,就抛出异常,默认-1表示不受限
consumer.timeout.ms = -1

#############################Producer#############################
# 核心的配置包括:
# metadata.broker.list
# request.required.acks
# producer.type
# serializer.class

# 消费者获取消息元信息(topics, partitions and replicas)的地址,配置格式是:host1:port1,host2:port2,也可以在外面设置一个vip
metadata.broker.list
 
#消息的确认模式
# 0:不保证消息的到达确认,只管发送,低延迟但是会出现消息的丢失,在某个server失败的情况下,有点像TCP
# 1:发送消息,并会等待leader 收到确认后,一定的可靠性
# -1:发送消息,等待leader收到确认,并进行复制操作后,才返回,最高的可靠性
request.required.acks = 0
 
# 消息发送的最长等待时间
request.timeout.ms = 10000
# socket的缓存大小
send.buffer.bytes=100*1024
# key的序列化方式,若是没有设置,同serializer.class
key.serializer.class
# 分区的策略,默认是取模
partitioner.class=kafka.producer.DefaultPartitioner
# 消息的压缩模式,默认是none,可以有gzip和snappy
compression.codec = none
# 可以针对默写特定的topic进行压缩
compressed.topics=null
# 消息发送失败后的重试次数
message.send.max.retries = 3
# 每次失败后的间隔时间
retry.backoff.ms = 100
# 生产者定时更新topic元信息的时间间隔 ,若是设置为0,那么会在每个消息发送后都去更新数据
topic.metadata.refresh.interval.ms = 600 * 1000
# 用户随意指定,但是不能重复,主要用于跟踪记录消息
client.id=""
 
# 异步模式下缓冲数据的最大时间。例如设置为100则会集合100ms内的消息后发送,这样会提高吞吐量,但是会增加消息发送的延时
queue.buffering.max.ms = 5000
# 异步模式下缓冲的最大消息数,同上
queue.buffering.max.messages = 10000
# 异步模式下,消息进入队列的等待时间。若是设置为0,则消息不等待,如果进入不了队列,则直接被抛弃
queue.enqueue.timeout.ms = -1
# 异步模式下,每次发送的消息数,当queue.buffering.max.messages或queue.buffering.max.ms满足条件之一时producer会触发发送。
batch.num.messages=200

Kafka集群端口无法监听及访问故障解决

出现问题的kafka版本是0.9.0.1,端口9099老是监听不起来,解决办法:
修改/usr/local/app/msg_server/kafka/0.9.0.1/config/server.properties文件的

listeners=PLAINTEXT://0.0.0.0:9099

这里的listeners也可以修换成内网IP地址,三台记得都修改,或者注释掉listeners增加advertised.listeners参数,
然后重启kafka即可

/usr/local/app/msg_server/kafka/0.9.0.1/bin/kafka-server-start.sh -daemon /usr/local/app/msg_server/kafka/0.9.0.1/config/server.properties 

advertised.listeners这个配置的含义,官网有解释:
Listeners to publish to ZooKeeper for clients to use, if different than the listeners above. In IaaS environments, this may need to be different from the interface to which the broker binds. If this is not set, the value for listeners will be used.
详情:http://kafka.apache.org/documentation/#configuration
kafka就会忽略listeners配置,用一个就可以了;

附server.properties配置文件内容:

# --------------------------------------------- need update
broker.id=0
listeners=PLAINTEXT://0.0.0.0:9099
#advertised.listeners=PLAINTEXT://10.249:9099
port=9099
default.replication.factor=3
# --------------------------------------------- need update
host.name=k1
# --------------------------------------------- need update
advertised.host.name=k1
advertised.port=9099
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
log.dirs=/usr/local/app/msg_server/kafka/0.9.0.1/data/
num.partitions=10
num.recovery.threads.per.data.dir=1
log.retention.hours=1
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
log.cleaner.enable=true
#zookeeper.connect=k1:2181
zookeeper.connect=k1:2181,k2:2181,k3:2181
zookeeper.connection.timeout.ms=6000
delete.topic.enable=true

Redis主从复制

redis主从复制,当用户往Master端写入数据时,通过Redis Sync机制将数据文件发送至Slave,Slave也会执行相同的操作确保数据一致;且实现Redis的主从复制非常简单。
redis的复制功能可以很好的实现数据库的读写分离,提高服务器的负载能力。主数据库主要进行写操作,而从数据库负责读操作。

过程:
1:当一个从数据库启动时,会向主数据库发送sync命令,

2:主数据库接收到sync命令后会开始在后台保存快照(执行rdb操作),并将保存期间接收到的命令缓存起来

3:当快照完成后,redis会将快照文件和所有缓存的命令发送给从数据库。

4:从数据库收到后,会载入快照文件并执行收到的缓存的命令。

注意:redis2.8之前的版本:当主从数据库同步的时候从数据库因为网络原因断开重连后会重新执行上述操作,不支持断点续传。
redis2.8之后支持断点续传,推荐安装最新版;

配置
Redis主从结构支持一主多从
主节点:172.17.11.35
从节点:172.17.11.36
注意:所有从节点的配置都一样

手动修改配置文件
只需要修改从节点中redis的配置文件中的slaveof属性启动redis节点即可

slaveof 172.17.11.35 6379

运行redis-cli 登录控制台info后可看到信息:

redis-cli 
127.0.0.1:6379> INFO
# Replication
role:slave
master_host:172.17.11.35
master_port:6379
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:21490
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:d5370a33ed6b49a24111ebac3e5d8f0a56a8a4aa
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:21490
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:21490

当然也可以动态设置
通过redis-cli 连接到从节点服务器,执行下面命令即可。

slaveof 172.17.11.35 6379

演示结果和手动方式一致。
同理在Master上用redis-cli登录控制台,使用info查看

# Replication
role:master
connected_slaves:1
slave0:ip=172.17.11.36,port=6379,state=online,offset=21644,lag=0
master_replid:d5370a33ed6b49a24111ebac3e5d8f0a56a8a4aa
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:21644
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:21644

注意事项
如果使用主从复制,那么要确保master激活了持久化,或者确保它不会在当掉后自动重启。
原因:
slave是master的完整备份,因此如果master通过一个空数据集重启,slave也会被清掉。
在配置redis复制功能的时候如果主数据库设置了密码,需要在从数据的配置文件中通过masterauth参数设置主数据库的密码,这样从数据库在连接主数据库时就会自动使用auth命令认证了。相当于做了一个免密码登录。

kafka Failed to send messages after 10 tries 问题解决

Tomcat工程报错如下:

2017-12-25 13:28:44,594 [dataQueueConsumer-3:ERROR] com.plocc.dc.consumer.FormatConsumer - kafka.common.FailedToSendMessageException: Failed to send messages aft
er 10 tries.
2017-12-25 13:28:44,489 [dataQueueConsumer-3:ERROR] kafka.producer.async.DefaultEventHandler - Failed to collate messages by topic, partition due to: Failed to f
etch topic metadata for topic: wifi.wifiuseri

从wifi车场推送回来的数据,无法写入kafka订阅里面,解决步骤:
1、先确认kafka几台机器的内网使用主机名能否正常通信,
ping z1 看主机名能否ping通;

2、检查kakfa能否正常列出主题

/usr/local/app/msg_server/kafka/0.8.2.1/bin/kafka-topics.sh --list --zookeeper k1:2181,k2:2181

3、查看/usr/local/app/msg_server/kafka/0.8.2.1/config/consumer.properties 文件
将zookeeper.connect=127.0.0.1:2181修改为zookeeper.connect=z1:2181
这里的z1主机名对应本机内网IP,依次将其他2个节点也修改,最后重启下kafka,同时web应用服务器的host里面也应该要有z1的解析,确认以上3点以后即可解决。

Kafka0.8.2.1删除主题并重建操作步骤

在启动kafka时候确保删除在server.properties中有delete.topic.enable的配置,

delete.topic.enable=true

执行删除主题命令:

/usr/local/app/msg_server/kafka/0.8.2.1/bin/kafka-topics.sh --delete --zookeeper k1:2181,k2:2181,k3:2181 --topic parking_enter

此时只是打上了删除标记,不会真正删除,用list显示会看到主题后面带上了 - marked for deletion

登陆zookeeper控制台并删除brokers、admin、config节点的对应内容:

/usr/local/app/msg_server/zookeeper/3.4.6/bin/zkCli.sh
rmr /brokers/topics/parking.enter
rmr /admin/delete_topics/parking.enter
rmr /config/delete_topics/parking.enter

关闭三台机器上的kafka进程,查看对应的数据文件,并删除,否则在创建同名主题的时候回自动打上marked for deletion标签

[kafka@wgq_idc_cache_3_41 data]$ ll /usr/local/app/msg_server/kafka/0.8.2.1/data  | grep parking_enter
drwxr-xr-x 2 kafka kafka  4096 10月 30 15:05 parking_enter-0
drwxr-xr-x 2 kafka kafka  4096 10月 30 19:27 parking_enter-1
drwxr-xr-x 2 kafka kafka  4096 10月 30 15:07 parking_enter-2
drwxr-xr-x 2 kafka kafka  4096 10月 30 10:51 parking_enter-3
drwxr-xr-x 2 kafka kafka  4096 10月 30 11:53 parking_enter-4
drwxr-xr-x 2 kafka kafka  4096 10月 30 16:25 parking_enter-5
drwxr-xr-x 2 kafka kafka  4096 10月 30 11:40 parking_enter-6
drwxr-xr-x 2 kafka kafka  4096 10月 30 13:17 parking_enter-7
drwxr-xr-x 2 kafka kafka  4096 10月 30 10:12 parking_enter-8
drwxr-xr-x 2 kafka kafka  4096 10月 30 10:51 parking_enter-9
rm /usr/local/app/msg_server/kafka/0.8.2.1/data/parking_enter-* -rf   #删除parking_enter开头的主题

三台都删除完以后,重新启动kafka和zookeeper进程,三台都启动ok以后,使用list查看主题:

/usr/local/app/msg_server/kafka/0.8.2.1/bin/kafka-topics.sh --list --zookeeper k1:2181,k2:2181,k3:2181

使用create创建主题

/usr/local/app/msg_server/kafka/0.8.2.1/bin/kafka-topics.sh --create --zookeeper k1:2181,k2:2181,k3:2181 --replication-factor 2 --partitions 10 --topic parking_enter

此处为创建同名主题,相当于删除后重建,完成。

redis overcommit memory (oom) 问题报错解决方法

一,什么是overcommit or oom问题
Linux对大部分申请内存的请求都回复"yes",以便能跑更多更大的程序。因为申请内存后,并不会马上使用内存。这种技术叫做Overcommit。当linux发现内存不足时,会发生OOM killer(OOM=out-of-memory)。它会选择杀死一些进程(用户态进程,不是内核线程),以便释放内存。


---阅读剩余部分---

Redis配置文件redis.conf参数详解

Redis配置文件redis.conf参数详解,基本兼容4.x及5.0版本:

/********************************* GENERAL *********************************/
// 是否作为守护进程运行
daemonize yes 

// 如以后台进程运行,则需指定一个pid,默认为/var/run/redis.pid
pidfile /var/run/redis.pid 

// Redis默认监听端口
port 6379 

tcp-backlog 511 

// 客户端闲置多少秒后,断开连接
timeout 0 

tcp-keepalive 0 

// 日志记录等级,有4个可选值,debug,verbose,notice,warning
loglevel notice 

// 指定日志输出的文件名,可设为/dev/null屏蔽日志
logfile "" 

// 可用数据库数,默认值为16,默认数据库为0
databases 16 

/****************************** SNAPSHOTTING 快照 *********************************/
// 保存数据到disk的策略
// 900 秒有 1 条改变保存到disk
save 900 1
// 300 秒有 10 条改变保存到disk
save 300 10
// 60 秒有 10000 条改变保存到disk
save 60 10000 

stop-writes-on-bgsave-error yes 

// 当dump .rdb数据库的时候是否压缩数据对象
rdbcompression yes 

rdbchecksum yes 

// 本地数据库文件名,默认值为dump.rdb
dbfilename dump.rdb 

// 本地数据库存放路径,默认值为 ./
dir ./ 

/*************************** REPLICATION Redis的复制配置 *********************************/ 

// 当本机为从服务时,设置主服务的IP及端口
// slaveof <masterip> <masterport> 

// 当本机为从服务时,设置主服务的连接密码
// masterauth <master-password> 

// 当从库同主机失去连接或者复制正在进行,从机库有两种运行方式
// 1) 如果slave-serve-stale-data设置为yes(默认设置),从库会继续相应客户端的请求
// 2) 如果slave-serve-stale-data是指为no,出去INFO和SLAVOF命令之外的任何请求都会返回一个错误"SYNC with master in progress"
slave-serve-stale-data yes 

slave-read-only yes 

repl-diskless-sync no 

repl-diskless-sync-delay 5 

// 从库会按照一个时间间隔向主库发送PINGs.可以通过repl-ping-slave-period设置这个时间间隔,默认是10秒
repl-ping-slave-period 10 

// repl-timeout 设置主库批量数据传输时间或者ping回复时间间隔,默认值是60秒
// 一定要确保repl-timeout大于repl-ping-slave-period
repl-timeout 60 

// 采用无延迟同步 默认no
repl-disable-tcp-nodelay yes 

slave-priority 100 

/********************************* SECURITY 安全 *********************************/ 

// 设置客户端连接后进行任何其他指定前需要使用的密码。
// 警告:因为redis速度相当快,所以在一台比较好的服务器下,一个外部的用户可以在一秒钟进行150K次的密码尝试,
这意味着你需要指定非常非常强大的密码来防止暴力破解
// requirepass foobared 

// 命令重命名.
// 在一个共享环境下可以重命名相对危险的命令。比如把CONFIG重名为一个不容易猜测的字符。
// 举例:
// rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
// 如果想删除一个命令,直接把它重命名为一个空字符""即可,如下:
// rename-command CONFIG "" 

/********************************* LIMITS 约束 *********************************/
// 最大可用内存 maxmemory <bytes> 536870912,即512M
maxmemory 536870912 

// 当内存达到最大值的时候Redis会选择删除哪些数据?有五种方式可供选择
//
// volatile-lru -> 利用LRU算法移除设置过过期时间的key (LRU:最近使用 Least Recently Used )
// allkeys-lru -> 利用LRU算法移除任何key
// volatile-random -> 移除设置过过期时间的随机key
// allkeys->random -> remove a random key, any key
// volatile-ttl -> 移除即将过期的key(minor TTL)
// noeviction -> 不移除任何可以,只是返回一个写错误
maxmemory-policy allkeys-lru 

// LRU 和 minimal TTL 算法都不是精准的算法,但是相对精确的算法(为了节省内存),随意你可以选择样本大小进行检测。
// Redis默认的灰选择3个样本进行检测,你可以通过maxmemory-samples进行设置
maxmemory-samples 3 

/********************************* APPEND ONLY MODE *********************************/ 

// 启用aof持久化方式
// 因为redis本身同步数据文件是按上面save条件来同步的,所以有的数据会在一段时间内只存在于内存中。默认值为no
appendonly yes 

// 更新日志文件名,默认值为appendonly.aof
appendfilename "appendonly.aof" 

// 收到写命令立即写入磁盘,最慢,保证完全的持久化
appendfsync always
// 每秒写入一次
appendfsync everysec
// 完全依赖OS,性能最好,持久化没保证
appendfsync no 

// 部署在同一机器的redis实例,把auto-aof-rewrite打开,因为cluster环境下内存占用基本一致
#关闭在aof rewrite的时候对新的写操作进行fsync
no-appendfsync-on-rewrite yes 

// Automatic rewrite of the append only file.
// AOF 自动重写
// 当AOF文件增长到一定大小的时候Redis能够调用 BGREWRITEAOF 对日志文件进行重写
//
// 它是这样工作的:Redis会记住上次进行些日志后文件的大小(如果从开机以来还没进行过重写,那日子大小在开机的时候确定)
//
// 基础大小会同现在的大小进行比较。如果现在的大小比基础大小大制定的百分比,重写功能将启动
// 同时需要指定一个最小大小用于AOF重写,这个用于阻止即使文件很小但是增长幅度很大也去重写AOF文件的情况
// 设置 percentage 为0就关闭这个特性
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb 

aof-load-truncated yes 

/********************************* LUA SCRIPTING *********************************/
lua-time-limit 5000 

/********************************* REDIS CLUSTER 集群*********************************/
// 打开redis集群
cluster-enabled yes 

// cluster配置文件(启动自动生成)
cluster-config-file nodes-6379.conf 

// 节点互连超时的阀值
cluster-node-timeout 15000 

cluster-slave-validity-factor 10 

cluster-migration-barrier 1 

// 集群兼容部分失败
cluster-require-full-coverage yes 

/********************************* SLOW LOG *********************************/

// Redis Slow Log 记录超过特定执行时间的命令。执行时间不包括I/O计算比如连接客户端,返回结果等,只是命令执行时间
//
// 可以通过两个参数设置slow log:一个是告诉Redis执行超过多少时间被记录的参数slowlog-log-slower-than(微妙),
// 另一个是slow log 的长度。当一个新命令被记录的时候最早的命令将被从队列中移除 

// 下面的时间以微妙微单位,因此1000000代表一分钟。
// 注意制定一个负数将关闭慢日志,而设置为0将强制每个命令都会记录
slowlog-log-slower-than 10000 

// 对日志长度没有限制,只是要注意它会消耗内存
// 可以通过 SLOWLOG RESET 回收被慢日志消耗的内存
slowlog-max-len 128 

/********************************* LATENCY MONITOR *********************************/ 

latency-monitor-threshold 0 

/********************************* EVENT NOTIFICATION *********************************/

notify-keyspace-events "" 

/********************************* ADVANCED CONFIG *********************************/ 

// 当hash中包含超过指定元素个数并且最大的元素没有超过临界时,
// hash将以一种特殊的编码方式(大大减少内存使用)来存储,这里可以设置这两个临界值
// Redis Hash对应Value内部实际就是一个HashMap,实际这里会有2种不同实现,
// 这个Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储,
而不会采用真正的HashMap结构,对应的value redisObject的encoding为zipmap, 

// 当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。 

hash-max-ziplist-entries 512
hash-max-ziplist-value 64 

// list数据类型多少节点以下会采用去指针的紧凑存储格式。
// list数据类型节点值大小小于多少字节会采用紧凑存储格式。
list-max-ziplist-entries 512
list-max-ziplist-value 64 

// set数据类型内部数据如果全部是数值型,且包含多少节点以下会采用紧凑格式存储。
set-max-intset-entries 512 

// zsort数据类型多少节点以下会采用去指针的紧凑存储格式。
// zsort数据类型节点值大小小于多少字节会采用紧凑存储格式。
zset-max-ziplist-entries 128
zset-max-ziplist-value 64 

hll-sparse-max-bytes 3000 

// Redis将在每100毫秒时使用1毫秒的CPU时间来对redis的hash表进行重新hash,可以降低内存的使用
//
// 当你的使用场景中,有非常严格的实时性需要,不能够接受Redis时不时的对请求有2毫秒的延迟的话,把这项配置为no。
//
// 如果没有这么严格的实时性要求,可以设置为yes,以便能够尽可能快的释放内存
activerehashing yes 

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60 

hz 10 

aof-rewrite-incremental-fsync yes 

/********************************* VM *********************************/

// 是否使用虚拟内存,默认值为no
vm-enabled yes

// 虚拟内存文件路径,默认值为/tmp/redis.swap,不可多个Redis实例共享
vm-swap-file /tmp/redis.swap

// 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的
(Redis的索引数据就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0。
vm-max-memory 0

// 虚拟内存文件以块存储,每块32bytes
vm-page-size 32

// 虚拟内在文件的最大数
vm-pages 134217728

// 可以设置访问swap文件的线程数,设置最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的.
可能会造成比较长时间的延迟,但是对数据完整性有很好的保证.
vm-max-threads 4

/********************************* INCLUDES *********************************/
// 包含通用配置
include /etc/redis/redis-common.conf 

/********************************* GENERAL *********************************/
// 如以后台进程运行,则需指定一个pid,默认为/var/run/redis.pid
pidfile /var/run/redis_6379.pid 

// Redis默认监听端口
port 6379 

// 指定日志输出的文件名,可设为/dev/null屏蔽日志
logfile /var/log/redis_6379.log 

/********************************* SNAPSHOTTING 快照 *********************************/ 

// 本地数据库文件名,默认值为dump.rdb
dbfilename dump6379.rdb 

// 本地数据库存放路径,默认值为 ./
dir /var/redis/6379 

/********************************* REPLICATION Redis的复制配置 *********************************/ 

// 当本机为从服务时,设置主服务的IP及端口
// slaveof <masterip> <masterport> 

// 当本机为从服务时,设置主服务的连接密码
// masterauth <master-password> 

/********************************* APPEND ONLY MODE *********************************/ 

// 更新日志文件名,默认值为appendonly.aof
appendfilename "appendonly6379.aof" 

/********************************* REDIS CLUSTER 集群 *********************************/

// cluster配置文件(启动自动生成)
cluster-config-file nodes-6379.conf

redis快速安装

确保机器能连外网,直接root登录执行:

wget http://download.redis.io/releases/redis-3.2.6.tar.gz
tar xvf redis-3.2.6.tar.gz
mv redis-3.2.6 /usr/local/redis
cd /usr/local/redis
make

安装完毕·
建立软连接:

ln -s /usr/local/redis/src/redis-cli /usr/bin/

按业务需求修改下redis.conf配置文件,常用需修改的参数有binddaemonizelogfileDIRvm.overcommit_memory等;
增加下面三个参数,防止redis因内存问题挂掉

maxmemory 5368709120
maxmemory-policy allkeys-lru
maxmemory-samples 3

使用redis用户启动redis进程:

useradd redis
chown -R redis.redis /usr/local/redis/
su - redis
/usr/local/redis/src/redis-server /usr/local/redis/redis.conf

完成.

最新

分类

归档

评论

  • 安安: 都是af
  • Liang: 嗯,有点不通顺·
  • 王庭威: “MySQL互为主从...
  • Liang: 贴下编译参数和步骤,...
  • shao3911: 您好,为什么我在编译...
  • aliang: 先看是yum安装还是...
  • aliang: 将原来的nginx安...
  • yen: 3、如果要回滚的话,...
  • yen: 刚好需要升级ngin...
  • 文雨: 一些新的method...

其它