Redis 学习小结

最近在学习Redis，将其记录，以备查看。

*****************redis适用场合****************

1.取最新N个数据的操作

2.排行榜应用,取TOP N 操作

3.需要精确设定过期时间的应用

4.计数器应用

5.Uniq操作,获取某段时间所有数据排重值

6.实时系统,反垃圾系统7.Pub/Sub构建实时消息系统

7.Pub/Sub构建实时消息系统8.构建队列系统

Redis高级特性

1.Redis安全性

 虽然redis没有实现访问控制这个功能，但是它提供了一个轻量级的认证方式，可以编辑redis.conf配置来启用认证。

当授权方式启用时，redis将会拒绝来自非认证用户的任何查询。用户可以通过发送AUTH命令并带上密码给redis服务器来给自己授权。

系统管理员在redis.conf文件里以明文方式设置密码。而且密码必须足够长来抵御暴力破解密码方式的攻击，这样设置密码做有两个原因：

（1）    redis的查询速度是非常快的，外部用户一秒内可以尝试许多个密码。

（2）    redis密码存储在redis服务器上的redis.conf文件以及用户的配置文件里，系统管理员没有必要记住密码，因为密码可以非常长的。

       AUTH命令跟其他redis命令一样，是没有加密的，所以阻止不了攻击者在网络上窃取你的密码。

对比memcache ,Redis 提供了轻量级的认证，而memcache没有任何认证机制。

2.主从复制

redis主从复制配置和使用都非常简单。通过主从复制可以允许多个slave server拥有和master server相同的数据库副本。

　　A、redis主从复制特点:

　　(1)、master可以拥有多个slave

　　(2)、多个slave可以连接同一个master外，还可以连接到其他slave

　　(3)、主从复制不会阻塞master，在同步数据时，master可以继续处理client请求

　　(4)、提高系统的伸缩性

　　B、redis主从复制过程:

　　当配置好slave后，slave与master建立连接，然后发送sync命令。无论是第一次连接还是重新连接，master都会启动一个后台进程，将数据库快照保存到文件中，同时master主进程会开始收集新的写命令并缓存。后台进程完成写文件后，master就发送文件给slave，slave将文件保存到硬盘上，再加载到内存中，接着master就会把缓存的命令转发给slave，后续master将收到的写命令发送给slave。如果master同时收到多个slave发来的同步连接命令，master只会启动一个进程来写数据库镜像，然后发送给所有的slave。

    C、配置主从服务器：
配置slave服务器：--在slave的配置文件中加入以下配置：
slaveof 192.168.1.1 6379        #指定master的ip和端口
masterauth lamp                #这是主机的密码
判断主从——调用Info指令。。
role:slave
master_link_up:up

主从复制总结

由于目前Redis的主从复制还不够成熟，所以存在明显的单点故障问题，这个目前只能自己做方案解决，如：主动复制，Proxy实现Slave对Master的替换等，这个也是Redis作者目前比较优先的任务之一，作者的解决方案思路简单优雅，详情可见 Redis Sentinel design drafthttp://redis.io/topics/sentinel-spec。

1. Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化。
2. 如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
3. 为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。
4. 尽量避免在压力较大的主库上增加从库
5. 为了Master的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：Master<–Slave1<–Slave2<–Slave3…….，这样的结构也方便解决单点故障问题，实现Slave对Master的替换，也即，如果Master挂了，可以立马启用Slave1做Master，其他不变。

3.Redis持久化机制:  

1.两种方式:一、备份数据到磁盘(快照)[ snapshotting(快照)也是默认方式]

   二、记录操作命令[ Append-only file(缩写aof)的方式]

一、备份数据到磁盘(快照)[ snapshotting(快照)也是默认方式] 

save 900 1 #900秒内如果超过1个key被修改,则发起快照保存

save 300 10 #300秒内容如超过10个key被修改,则发起快照保存

save 60 10000

二、记录操作命令[ Append-only file(缩写aof)的方式](较安全持久化) 

appendonly yes #启用aof 持久化方式 

# appendfsync always //收到写命令就立即写入磁盘,最慢,但是保证完全的持久化 

appendfsync everysec //每秒钟写入磁盘一次,在性能和持久化方面做了很好的折中

# appendfsync no //完全依赖os,性能最好,持久化没保证

4.pub/sub

发布订阅(pub/sub)是一种消息通信模式，主要的目的是解耦消息发布者和消息订阅者之间的耦合，这点和设计模式中的观察者模式比较相似。pub/sub不仅仅解决发布者和订阅者直接代码级别耦合也解决两者在物理部署上的耦合。redis作为一个pub/sub的server，在订阅者和发布者之间起到了消息路由的功能。订阅者可以通过subscribe和psubscribe命令向redis server订阅自己感兴趣的消息类型，redis将消息类型称为通道(channel)。当发布者通过publish命令向redis server发送特定类型的消息时。订阅该消息类型的全部client都会收到此消息。这里消息的传递是多对多的。一个client可以订阅多个channel,也可以向多个channel发送消息。

附：MySQL的Replication

http://www.cnblogs.com/weafer/archive/2011/09/20/2182566.html

MySQL的Replication是一种多个MySQL的数据库做主从同步的方案，特点是异步，广泛用在各种对MySQL有更高性能，更高可靠性要求的场合。与之对应的另一个技术是同步的MySQL Cluster，但因为比较复杂，使用者较少。
 
下图是MySQL官方给出了使用Replication的场景：

Replication原理
 
Mysql 的 Replication 是一个异步的复制过程，从一个MySQL节点（称之为Master）复制到另一个MySQL节点（称之Slave）。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程（SQL 线程和 I/O 线程）在 Slave 端，另外一个线程（I/O 线程）在 Master 端。
 
要实现 MySQL 的 Replication ，首先必须打开 Master 端的 Binary Log，因为整个复制过程实际上就是 Slave 从 Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。
 
看上去MySQL的Replication原理非常简单，总结一下：
     * 每个从仅可以设置一个主。
    * 主在执行sql之后，记录二进制log文件（bin-log）。
    * 从连接主，并从主获取binlog，存于本地relay-log，并从上次记住的位置起执行sql，一旦遇到错误则停止同步。
  
从这几条Replication原理来看，可以有这些推论：
     * 主从间的数据库不是实时同步，就算网络连接正常，也存在瞬间，主从数据不一致。
    * 如果主从的网络断开，从会在网络正常后，批量同步。
    * 如果对从进行修改数据，那么很可能从在执行主的bin-log时出现错误而停止同步，这个是很危险的操作。所以一般情况下，非常小心的修改从上的数据。
    * 一个衍生的配置是双主，互为主从配置，只要双方的修改不冲突，可以工作良好。
    * 如果需要多主的话，可以用环形配置，这样任意一个节点的修改都可以同步到所有节点。
  
主从设置
 
因为原理比较简单，所以Replication从MySQL 3就支持，并在所有平台下可以工作，多个MySQL节点甚至可以不同平台，不同版本，不同局域网。做Replication配置包括用户和my.ini（linux下为my.cnf）两处设置。
 
首先在主MySQL节点上，为slave创建一个用户：
 
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'192.168.1.10' IDENTIFIED BY 'slave';
 
实际上，为支持主从动态同步，或者手动切换，一般都是在所有主从节点上创建好这个用户。然后就是MySQL本身的配置了，这需要修改my.cnf或者my.ini文件。在mysqld这一节下面增加：
 
server-id=1   
auto-increment-increment=2    
auto-increment-offset=1    
log-bin    
binlog-do-db=mstest    
binlog_format=mixed
 
master-host=192.168.1.62   
master-user=slave    
master-password=slave    
replicate-do-db=mstest
 
上面这两段设置，前一段是为主而设置，后一段是为从设置的。也就是说在两个MySQL节点上，各加一段就好。binlog-do-db和replicate-do-db就是设置相应的需要做同步的数据库了，auto-increment-increment和auto-increment-offset是为了支持双主而设置的（参考下一节），在只做主从的时候，也可以不设置。
 
双主的设置
 
从原理论来看MySQL也支持双主的设置，即两个MySQL节点互为主备，不过虽然理论上，双主只要数据不冲突就可以工作的很好，但实际情况中还是很容发生数据冲突的，比如在同步完成之前，双方都修改同一条记录。因此在实际中，最好不要让两边同时修改。即逻辑上仍按照主从的方式工作。但双主的设置仍然是有意义的，因为这样做之后，切换主备会变的很简单。因为在出现故障后，如果之前配置了双主，则直接切换主备会很容易。
  双主在设置时，只需将上面的一段设置复制一份，分别写入两个MySQL节点的配置文件，但要修改相应的server-id，auto-increment-offset和master-host。auto-increment-offset就是为了让双主同时在一张表中进行添加操作时不会出现id冲突，所以在两个节点上auto-increment-offset设置为不同的值就好。  另：不要忘了，在两个节点上都为对方创建用户。 应用层的负载均衡  本文只介绍了MySQL自身的Repilication配置，在上面的图中也可以看出，有了Replication，还需要应用层（或者中间件）做一个负载均衡，这样才能最大程度发挥MySQL Replication的优势，这些将在以后探讨。