利用下班时间，我两星期完成了redis入门与进阶

过去的两周，小松陆陆续续看完了一门长达十几个小时的课程 redis入门与精通。

固然，仅仅课程是不足以精通redis的，不过用来入门和窥见redis的全貌大有帮助，今天，小松就记录一下过去两周在redis上的学习心得。

基础

五大基本类型

key 这是最基础的，Redis是典型的键值对数据库，key能够经过runoobkey设置，若是设置成功就会返回OK，删除返回1。

redis 127.0.0.1:6379> SET runoobkey redis
OK
redis 127.0.0.1:6379> DEL runoobkey
(integer) 1
复制代码

String 这是最基础的类型，相比起来，mysql的类型是真的多，光一个int都要好几种。 而redis因为是key-value结构，他的key基本都是使用的String，而value也大量使用，因此String使用很是频繁。 最简单的时候方式是set，get，固然，也支持各类对string的操做。

redis 127.0.0.1:6379> SET runoobkey redis
OK
redis 127.0.0.1:6379> GET runoobkey
"redis"
复制代码

list list你们都不陌生，和数据结构同样，使用LPush命令在左边插入数据，RPush在右边插入数据。 相似的，有LPop，LTrim（截取），LRem（删除），LRANGE(查看）等操做，redis中字母不区分大小写。 这是在菜鸟教程中截取的例子。

127.0.0.1:6379>LPUSH list1 "foo"
(integer) 1
127.0.0.1:6379> LPUSH list1 "bar"
(integer) 2
127.0.0.1:6379> LRANGE list1 0 -1
1) "bar"
2) "foo"
复制代码

set set也很简单，命令包括SAdd，SCard(查看元素个数)，SRem，SUion(取并集)，SInter（取交集）等。 好比b站里面的共同关注就是经过SInter获取。 一个帐号的粉丝存储在一个Set中，两个帐号就有两个Set，只要将两个Set进行SInter，就能够知道同时关注这两个帐号的人了。

redis 127.0.0.1:6379> SADD runoobkey redis
(integer) 1
redis 127.0.0.1:6379> SADD runoobkey mongodb
(integer) 1
redis 127.0.0.1:6379> SADD runoobkey mysql
(integer) 1
redis 127.0.0.1:6379> SADD runoobkey mysql
(integer) 0
redis 127.0.0.1:6379> SMEMBERS runoobkey

1) "mysql"
2) "mongodb"
3) "redis"
复制代码

hash 这就是java中的map或者python中的dict，在redis中，叫作hash，案例和上面相似，就不贴了，无外乎hset，hget，hmset(批量设置)，hlen等。

进阶

持久化

持久化分为两种，持久化简单说就是要长期保存数据库，对于长期保存同样东西，思路就是要么保存过程，继而推导出结果，要么直接保存结果，因此这就是RDB和AOF。

RDB RDB的原理是，从父进程fork一个子进程，写入临时RDB，而后替换原来的快照，成为正式的RDB，在此期间，父进程，也就是原有的运行进程，正常运行

因此他就是作了一个对结果的备份，放在一个后缀为rdb格式的文件中而已

当须要恢复的时候，将rdb放在redis的启动目录，这样，启动redis时，rdb同步写入redis，就完成了恢复，他有如下特色

优势： 1. 适合大规模数据恢复。 2. 适合备份数据库，做为后备兜底用途。 缺点： 1. 须要必定时间间隔进行操做，由于不能每时每刻都备份，好比每隔1小时备份，那么一旦宕机，就会损失一小时的数据。 2. fork进程消耗资源。

AOF AOF相比起RDB，是更加经常使用的方式。

原理是将全部的命令记录下来，写入一个叫作appendonly.aof的文件中，当手动开启后，重启redis就会出现，很简单，并且因为保存的是步骤，而不是数据库自己，因此安全性高，他有三种同步方式，每一次修改都同步，每秒同步，从不一样步，有如下特色：

优势： 1. 若是设置每一次修改都同步，很方便，不会有损失。 2. 若是设置每秒同步，最多丢失一秒数据。 3. 每次重启redis，优先载入aof恢复数据。

缺点： aof的体积大于Rdb文件，并且恢复也比较慢，这个好理解，记录了那些步骤都要从新执行一遍，天然比rdb直接备份的要慢一些。

因此，根据他们的原理和优缺点，咱们很容易判断他们的使用范围。 若是是数据比较重要，可是能够承受损失，好比微博评论啥的，就用rdb吧。 若是须要更加安全，不能有损失，就用aof。 固然，两个都用也ok，aof用做平时的恢复，rdb用于紧急的兜底备份。

发布订阅

相似于微信公众号，信息消费者（subscriber）和信息生产者（Publisher ）经过中间的channel进行链接，须要subscriber先订阅，而后Publisher 将信息推入到channel中，这里的channel本质上是一个键。 redis会维护一个字典，每一个channel都是键，对应的值是一个链表，包含了全部的subscriber，因此当信息被推入channel中，信息就知道了他要去的地方，是那个链表，而后逐一分发下去。

主从复制

鸡蛋不能放在一个篮子里面，凡是涉及到数据库的，都须要进行备份，只不过各家的方式不同。 redis使用主从复制，一个最简单的模型是一主二从，使用三台电脑。

先思考一下，咱们须要解决哪些问题？ 基础功能：

1. 数据不能乱，读写要和一台机器同样。

方案：主机才有权力写，而从机只能从主机复制内容。

2. 若是主机挂了，从机可以及时变成主机。

方案：哨兵模式。

哨兵模式

我第一次接触哨兵模式，是在学习计算机系统的时候，所谓哨兵，至关于中世纪的教皇，而主机，是国王。 国王须要接受教皇的册封，才能成为真正的国王。

当主机挂掉的时候，哨兵将选择一个从机，让他成为主机，并且，即便原来的主机回来了，他也只能变成从机。 选择的方式，是投票。 哨兵不仅一个，是奇数个，对于三个服务器，一主二从，这里三个哨兵比较合适，定时向主机发送消息监控，若是三个哨兵都没法收到主机的回包，大几率主机就挂掉了，此时哨兵进行投票，得票多的从机成为主机，以下图 sentinel为哨兵，slave为从机。

投票是一种算法，这里再也不深刻。 而如何防止哨兵挂掉呢？这就是为何哨兵不仅一个的缘由，多个哨兵也相互监督。

这样，这个模型若是不断扩大，除非大面积断电，否则即便有一些哨兵或者服务器挂掉了，也能够正常运行。

缓存雪崩

黑天鹅仍是来了，大面积断电了！ 此时，就是缓存雪崩，由于断电，Redis做为内存数据库，做为访问与数据库之间的中间缓存，将会完全失效，此时 缓存称为雪崩。 方案在思路上没啥神奇的办法，只能异地容灾，或者提早预热，好比在11月10号模拟几亿订单量冲击淘宝系统，看看能不能抗住。

穿透

雪崩毕竟是天灾，咱们没法改变，可是缓存穿透咱们能够有所做为 穿透，就是缓存没起到做用，为何没起到做用？ 由于在缓存中没找到数据，好比说，用户找一个商品信息，可是缓存中找不到，因此会跳转到数据库中去找，而若是大量用户都来发起访问没找到的数据，数据库将会直接暴露，容易受到攻击，好比下图，若是一直是否，就会一直查询DB

主流解决方法是使用过滤器，好比著名的布隆过滤器，筛选出容易形成穿透的访问信息，剔除掉便可，至关于给缓存打了一个补丁，除了过滤，还能够分流，降级等等，这些东西，和几千年前的大禹治水的思路同样，只是搬到了计算机上，毕竟，智慧，古往今来，都不会变，变的是使用场景。

击穿

穿透是找不到，击穿是受不了，假设缓存中有这个商品信息，可是因为访问过于频繁，使得缓存也受不了，就会崩掉，好比微博某明星谈恋爱就崩了，这应该是属于缓存击穿案例。 方案也不难，可使用临界区，只要一部分在在访问，其余的就没法访问，这是一种互斥锁的方案，虽然并发少了，可是至少不会崩。

总结：以上就是小松两周来的一些收获，天天接近11点下班，也不能懈怠鸭，小松本身也运营一个公众号，【小松漫步】，专门记录小松的编程成长，还有大量电子书资源，有兴趣能够去逛逛哦