redis configuration and usage
1. Installation:
cd /usr/src
tar xzf redis-3.0.7.tar.gz
cd redis-3.0.7
make
cd src
make install PREFIX=/usr/local/redis
mkdir /usr/local/redis/etc/
mv redis.conf /usr/local/redis/etc/
start up:
/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf
/usr/local/redis/bin/redis-cli shutdown
Two, placement
echo 1 > /proc/sys/vm/overcommit_memory
echo 511 > /proc/sys/net/core/somaxconn
echo never > /sys/kernel/mm/transparent_hugepage/enabled
1. Allow external access:
firewall-cmd --zone=public --add-port=6379/tcp
/usr/local/redis/bin/redis-cli
CONFIG SET protected-mode no
CONFIG REWRITE
2. Configuration file example:
include /usr/local/redis/etc/redis.conf
port 6379
pidfile "/root/workspace/java/redis_6379.pid"
# debug notice warning
loglevel notice
logfile "/root/workspace/java/redis.log"
dbfilename "dump.rdb"
dir "/usr/src/redis-3.2.9"
3. Use lua script, the spaces on both sides represent keys and parameters
redis-cli -p 6379 --ldb --eval api.lua k1 k2 , arg1 arg2
3. Master-slave replication
Increase redundancy reliability, scalability, the main library avoids io. To a certain extent, the C in the CAP is guaranteed.
1. Process
1》slave -> mastr SYNC
2> master bgsave（rdb）
3 "Send to slave for subsequent modification
2. Configuration:
slave server
SLAVEOF 192.168.1.1 10086
config set masterauth <password> 或 masterauth pwd
Master server:
min-slaves-to-write <number of slaves>
min-slaves-max-lag <number of seconds>
4. HA High Availability
1. CAP theory:
C (Consistency): The data on all nodes is always synchronized
A (availability): Each request receives a response, whether the response succeeds or fails
P (Partition Tolerance): The system should continue to provide service even if messages are lost inside the system (partition)
High availability and data consistency are the goals of many system designs, but partitioning is inevitable:
CA without P: If P is not required (no partition allowed), then C (strong consistency) and A (availability) are guaranteed. But in fact, partitioning is not a question of whether you want it or not, but will always exist. Therefore, the CA system is more to allow each subsystem to remain CA after partitioning.
CP without A: If A (available) is not required, it means that each request needs to be strongly consistent between servers, and P (partition) will cause the synchronization time to be extended indefinitely, so CP can also be guaranteed. Many traditional database distributed transactions fall into this pattern.
AP wihtout C: To be highly available and allow partitioning, you need to give up consistency. Once a partition occurs, the nodes may lose contact. For high availability, each node can only provide services with local data, which will lead to inconsistency of global data. Many NoSQLs now fall into this category.
CP is suitable for finance, AP is suitable for games
2. Redis persistence format
rdb: fast
aof: similar to mysql binlog, more reliable
Disaster recovery: copy the rdb file
3. Sentinel: failover to ensure availability
redis-server /path/to/sentinel.conf --sentinel
Configuration example:
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5
Five, cluster cluster (server-side transparent sharding and failover)
1. Semi-automatic tool redis-trib.rb