auto commit
This commit is contained in:
CyC2018
@ -10,9 +10,11 @@
|
||||
* [发布与订阅](#发布与订阅)
|
||||
* [事务](#事务)
|
||||
* [持久化](#持久化)
|
||||
* [1. 快照持久化](#1-快照持久化)
|
||||
* [2. AOF 持久化](#2-aof-持久化)
|
||||
* [快照持久化](#快照持久化)
|
||||
* [AOF 持久化](#aof-持久化)
|
||||
* [复制](#复制)
|
||||
* [从服务器连接主服务器的过程](#从服务器连接主服务器的过程)
|
||||
* [主从链](#主从链)
|
||||
* [处理故障](#处理故障)
|
||||
* [分片](#分片)
|
||||
* [事件](#事件)
|
||||
@ -212,7 +214,7 @@ MULTI 和 EXEC 中的操作将会一次性发送给服务器，而不是一条
|
||||
|
||||
Redis 是内存型数据库，为了保证数据在断电后不会丢失，需要将内存中的数据持久化到硬盘上。
|
||||
|
||||
## 1. 快照持久化
|
||||
## 快照持久化
|
||||
|
||||
将某个时间点的所有数据都存放到硬盘上。
|
||||
|
||||
@ -220,7 +222,7 @@ Redis 是内存型数据库，为了保证数据在断电后不会丢失，需
|
||||
|
||||
如果系统发生故障，将会丢失最后一次创建快照之后的数据。并且如果数据量很大，保存快照的时间也会很长。
|
||||
|
||||
## 2. AOF 持久化
|
||||
## AOF 持久化
|
||||
|
||||
AOF 持久化将写命令添加到 AOF 文件（Append Only File）的末尾。
|
||||
|
||||
@ -242,17 +244,17 @@ always 选项会严重减低服务器的性能；everysec 选项比较合适，
|
||||
|
||||
一个从服务器只能有一个主服务器，并且不支持主主复制。
|
||||
|
||||
**1. 从服务器连接主服务器的过程**
|
||||
## 从服务器连接主服务器的过程
|
||||
|
||||
(1) 主服务器创建快照文件，发送给从服务器，并在发送期间使用缓冲区记录执行的写命令。快照文件发送完毕之后，开始向从服务器发送存储在缓冲区中的写命令；
|
||||
(2) 从服务器丢弃所有旧数据，载入主服务器发来的快照文件，之后从服务器开始接受主服务器发来的写命令；
|
||||
(3) 主服务器每执行一次写命令，就向从服务器发送相同的写命令。
|
||||
- 主服务器创建快照文件，发送给从服务器，并在发送期间使用缓冲区记录执行的写命令。快照文件发送完毕之后，开始向从服务器发送存储在缓冲区中的写命令；
|
||||
- 从服务器丢弃所有旧数据，载入主服务器发来的快照文件，之后从服务器开始接受主服务器发来的写命令；
|
||||
- 主服务器每执行一次写命令，就向从服务器发送相同的写命令。
|
||||
|
||||
**2. 主从链**
|
||||
## 主从链
|
||||
|
||||
随着负载不断上升，主服务器可能无法很快地更新所有从服务器，或者重新连接和重新同步从服务器而导致系统超载。为了解决这个问题，可以创建一个中间层来分担主服务器的复制工作。中间层的服务器是最上层服务器的从服务器，又是最下层服务器的主服务器。
|
||||
随着负载不断上升，主服务器可能无法很快地更新所有从服务器，或者重新连接和重新同步从服务器将导致系统超载。为了解决这个问题，可以创建一个中间层来分担主服务器的复制工作。中间层的服务器是最上层服务器的从服务器，又是最下层服务器的主服务器。
|
||||
|
||||
<div align="center"> <img src="index_files/b242fafc-5945-42a8-805e-6e3f1f2f89b4.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//b242fafc-5945-42a8-805e-6e3f1f2f89b4.jpg"/> </div><br>
|
||||
|
||||
# 处理故障
|
||||
|
||||
@ -338,7 +340,7 @@ def main():
|
||||
|
||||
事件处理的角度下服务器运行流程如下：
|
||||
|
||||
<div align="center"> <img src="index_files/73b73189-9e95-47e5-91d0-9378b8462e15.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//73b73189-9e95-47e5-91d0-9378b8462e15.png"/> </div><br>
|
||||
|
||||
# Redis 与 Memcached 的区别
|
||||
|
||||
@ -411,7 +413,7 @@ Redis 这种内存数据库才能支持计数器的频繁读写操作。
|
||||
|
||||
Redis 没有表的概念将同类型的数据存放在一起，而是使用命名空间的方式来实现这一功能。键名的前面部分存储命名空间，后面部分的内容存储 ID，通常使用 : 来进行分隔。例如下面的 HASH 的键名为 article:92617，其中 article 为命名空间，ID 为 92617。
|
||||
|
||||
<div align="center"> <img src="index_files/2d078e08-3a49-46d0-b784-df780b7e4bc3.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//2d078e08-3a49-46d0-b784-df780b7e4bc3.jpg"/> </div><br>
|
||||
|
||||
**2. 点赞功能**
|
||||
|
||||
@ -419,13 +421,13 @@ Redis 没有表的概念将同类型的数据存放在一起，而是使用命
|
||||
|
||||
为了节约内存，规定一篇文章发布满一周之后，就不能再对它进行投票，而文章的已投票集合也会被删除，可以为文章的已投票集合设置一个一周的过期时间就能实现这个规定。
|
||||
|
||||
<div align="center"> <img src="index_files/0e4c8a7f-f84c-4c4e-9544-49cd40167af8.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//0e4c8a7f-f84c-4c4e-9544-49cd40167af8.png"/> </div><br>
|
||||
|
||||
**3. 对文章进行排序**
|
||||
|
||||
为了按发布时间和点赞数进行排序，可以建立一个文章发布时间的有序集合和一个文章点赞数的有序集合。（下图中的 score 就是这里所说的点赞数；下面所示的有序集合分值并不直接是时间和点赞数，而是根据它们间接计算出来的）
|
||||
|
||||
<div align="center"> <img src="index_files/ea5e434a-a218-44b5-aa72-4cd08991abcf.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//ea5e434a-a218-44b5-aa72-4cd08991abcf.jpg"/> </div><br>
|
||||
|
||||
# 参考资料
|
||||
|
||||
|
||||
Reference in New Issue
Block a user