redis概述
Redis是Salvatore Sanfilippo在2009年為其初創公司LLOOGG開發的，目前仍是獨立項目，但VMWare贊劣了項目（作者是其雇員）。它采用C語言實現，因此性能很好。采用BSD許可證，使用鍵值存儲，和Amazon Dynamo，Cassandra，Riak，Voldemort，Memcache類似。支持豐富的數據類型，比如數組，鏈表，集合等，非常適合需要表達時間線的web服務，例如微博。
Redis支持的數據類型有：
1.字符串
2.鏈表
3.集合
4.有序集合
5.散列表
Redis的主從復制
Redis自帶有主從復制的功能，只要設置配置文件redis.conf的slaveof選項即可，如下所示：
但我們可以使用keepalived+redis的方法實現高可用，如下所示：
- redis的配置
- 主機 端口 角色
- redis0 6379 master
- redis1 6379 slave
- keepalived的配置
- redis0和redis1使用一個虛擬ip
并使用如下腳本監控redis服務是否存活：
#!/bin/bash /usr/local/bin/redis-cli -h 192.168.1.53 -p 6379 info > /dev/null if [ $? -eq 0 ]; then echo "redis OK" exit 0 else echo "no redis service found!" /usr/local/bin/redis-server /path/to/redis.conf # try to start it again /usr/local/bin/redis-cli -h 192.168.11.53 -p 6380 info > /dev/null if [ $? -eq 0 ]; then exit 0 else # restart failed killall keepalived echo "error" fi fi
要實現redis的故障恢復，可以使用keepalived配置的notify_master, notify_backup這兩個方法執行特有的腳本。實際上只要在slave(即redis1)上有2個腳本，第一個用于在redis1接管虛擬ip之后，執行slaveof no one把自己變成master。第二個是在redis1交出虛擬ip之后，在redis0執行slaveof no one確保redis0恢復為主的狀態，并對redis1執行slaveof redis0 6379開始重新從master同步數據，如果自己已經是slave就沒必要同步了。
redis1上keepalived的配置方法如下，redis0只要去掉notify_master, notify_backup兩行即可。
! Configuration File for keepalived
global_defs {
router_id redis1
}
vrrp_script Monitor_Redis {
script "/opt/redis_keepalive.sh"
interval 10
weight 2
}
vrrp_instance 360 {
state BUCKUP #(主機為MASTER，備用機為BACKUP)
interface eth0 #(HA監測網絡接口)
virtual_router_id 110 #(主、備機的virtual_router_id必須相同)
mcast_src_ip 192.168.11.53 #(多播的源IP，設置為本機外網IP，與VIP同一網卡)此項可不設置
priority 70 #(主、備機取不同的優先級，主機值較大，備份機值較小,值越大優先級越高)
advert_int 1 #(VRRP Multicast廣播周期秒數)
authentication {
......
}
notify_master /opt/redis_2master.sh
notify_backup /opt/redis_2backup.sh
track_script {
Monitor_Redis #(調用Nginx進程檢測腳本)
}
virtual_ipaddress {
192.168.11.4 #(VRRP HA虛擬地址)
}
}
Redis的持久化
Redis的有以下2種的持久化機制：
1.快照（snapshot）
2.AOF（Append Only File）
Redis的快照功能配置如下：
Redis快照原理如下：
Redis借助了fork命令的copy on write機制。在生成快照時，將當前迚程fork出一個子進程，然后在子迚程中循環所有的數據，將數據寫成為RDB文件。
Redis原來的RDB文件不會壞掉，因為其寫操作是在一個新迚程中迚行的，當生成一個新的，RDB文件時，Redis生成的子迚程會先將數據寫到一個臨時文件中，然后通過原子性rename系統調用將臨時文件重命名為RDB文件，這樣在仸何時候出現故障，Redis的RDB文件都總是可用的。
同時，Redis的RDB文件也是Redis主從同步內部實現中的一環。
我們可以很明顯的看到，RDB有它的不足，就是一旦數據庫出現問題，那么我們的RDB文件中保存的數據并不是全新的，從上次RDB文件生成到Redis停機這段時間的數據全部丟掉了。在某些業務下，這是可以忍受的，我們也推薦這些業務使用RDB的方式進行持久化，因為開啟RDB的代價并不高。
AOF的配置如下：
AOF優先于RDB（即快照），RDB性能優于AOF，因為里面沒有重復。
AOF Rewrite:
重新生成一份AOF文件，新的AOF文件中一條記錄的操作只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的多次操作。其生成過程和RDB類似， 也是fork一個進程，直接遍歷數據，寫入新的AOF臨時文件。在寫入新文件的過程中，所有的寫操作日志還是會寫到原來老的 AOF文件中，同時還會記錄在內存緩沖區中。當重完操作完成后，會將所有緩沖區中的日志一次性寫入到臨時文件中。然后調用原子性的rename命令用新的 AOF文件取代老的AOF文件。
謝謝你的閱讀，如果您覺得這篇博文對你有幫助，請點贊或者喜歡，讓更多的人看到！祝你每天開心愉快！
