文章开始啰嗦两句,写到这里共21篇关于redis的琐碎知识,没有过多的写编程过程中redis的应用,着重写的是redis命令、客户端、服务器以及生产环境搭建用到的主从、哨兵、集群实现原理,如果你真的能看的进去,相信对你在以后用到redis时会有一定的帮助。

写到现在,redis相关的内容暂时告一段落了,以后可能更着重的去介绍c#相关的知识,包括用到IL、.net core底层、微服务等知识。

哎呀,写着写着突然又想啰嗦几句,最近几年c#在国内式微java如日中天,好多微软系的小伙伴或者各路大神都不看好c#,网上相关的帖子更是多如牛毛,另外一个现象就是从职位到薪资被java、go等语言甩了n条街。

但我觉得抛开这些外界因素,单从技术或者说是语言上讲c#其实非常优秀,虽然近几年.net  core 有些不伦不类、各种借鉴(抄袭)其他语言的语法糖、各个大版本之间不兼容等问题一堆,但是这并不影响他的优秀,毕竟成长确实要走很多弯路,所以希望有兴趣继续搞搞.net 的童鞋可以持续关注c#。


 

Redis通过MULTI、EXEC、WATCH等命令来实现事务,事务提供了一种将多个命令请求打包,然后一次性、按顺序地执行多个命令的机制,并且在事务执行期间,服务器不会中断事务而改去执行其他客户端命令请求,他会将事务中的所有命令执行完毕,然后采取处理其他客户端的命令请求。

一个事务从开始到结束通常会经历以下三个阶段:事务开始、命令入队、事务执行。

1)事务开始

MULTI命令的执行标志是事务的开始,MULTI命令可以将执行该命令的客户端的从非事务状态切换至事务状态,这一切是通过在客户端状态的flags属性中打开REDIS_MULTI标识来完成的。

2)命令入队

如果客户端发送的命令为EXEC、DISCARD、WATCH、MULTI四个命令的其中一个,那么服务器立即执行这个命令,相反,服务器并不会立即执行这个命令,而是将命令放入到一个事务队列中,而后向客户端返回QUEUED回复。

每个Redis客户端都有自己的事务状态,这个事务状态保存在客户端状态的mstate属性里面:

typedef struct redisClient{
    //事务状态
    multiState mstate;
} redisClient;

事务状态包含一个事务队列,以及一个已入队命令的计数器:

typedef struct multiState{
    //事务队列,FIFO顺序
    multiCmd *commands;
    ///已入队列计数
    int count;
} multiState;
typedef struct multiCmd{
    //参数
    robj **argv;
    //参数数量
    int argc;
    //命令指针
    struct redisCommand *cmd;
} multiCmd;

事务队列以先进先出的方式 保存入队的命令。

3)执行事务

当一个处于事务状态的客户端向服务器发送EXEC命令时,这个EXEC命令将立即被服务器执行。服务器会遍历这个客户端的事务队列,执行队列中保存的所有命令,最后将执行命令所得的结果全部返回给客户端。

WATCH命令

watch命令是一个乐观锁,它可以在exec命令执行之前,监视任意数量的数据库键,并在EXEC命令执行时,检查被监视的键是否至少有一个已经被修改过,如果是的话,服务器将拒绝执行事务,并向客户端返回标识事务执行失败的空回复。

每个Redis数据库都保存着一个watched_keys字典,这个键是某个被watch命令监视的数据数据库键,而字典的值是一个链表,链表中记录了所有被监视相应数据库键的客户端。

typedef struct redisDb{
    //正在被watch命令监视的键
    dict *watched_keys;
} redisDb;

监视机制的触发:所有对数据库进行修改的命令,在执行之后都会调用touchWatchKey函数对watched_keys字典进行检查,查看是否在客户端正在监视刚刚被命令修改过的数据库键,如果有的话,那么touchWatchKey函数会将监视被修改键的客户端的REDIS_DIRTY_CAS标识打开,标识该客户端的事务安全性已经被破坏。

 

判断事务是否安全

当服务器接收到一个客户端发来的EXEC命令时,服务器会根据客户端是否打开REDIS_DIRTY_CAS标识来决定是否执行事务:如果客户端的REDIS_DIRTY_CAS标识已经被打开,那么说明客户端所监视的键当中,至少有一个键已经被修改过了,在这种情况下,客户端提交的事务已经不再安全,所以服务器会拒绝执行客户端提交的事务;如果客户端REDIS_DIRTY_CAS标识没有被打开,那么说明客户端监视的所有键都没有被修改过,事务仍然是安全的,服务器将执行客户端提交的这个事务。

 

事务的ACID性质

原子性:Redis的事务和传统的关系型数据库事务最大的区别在于,Redis不支持事务回滚机制,事务队列中的某个命令在执行期间出现错误,整个事务也会继续执行下去,直到将事务队列中的所有命令都执行完毕为止。

一致性:

1、入队错误,如果一个事务在入队命令的过程中,出现了命令不存在,或者命令的格式不正确的情况那么Redis将拒绝执行这个事务

2、执行错误:执行过程中发生的错误都是一些不能再入队时被服务器发现的错误,这些错误只会在命令实际执行时被触发;即使在事务的执行过程中发生了错误,服务器也不会中断事务的执行,他会继续执行事务中余下的其他命令,并且一致性的命令不会被出错的命令影响。

3、服务器停机:如果服务器运行在无持久化的内存模式中,那么重启之后数据库将是一片空白的,因此数据总是一致性的;如果服务器运行了RDB模式下,那么事务中途停机不会导致不一致性,因为服务器可以根据现有的RDB文件来恢复数据,从而将数据库还原到一个一致性的状态。如果服务器运行在APF模式下,那么事务中途停机不会导致不一致性,因为服务器可以根据现有的APF文件来恢复数据,从而将数据库还原至一致的状态。

隔离性:Redis使用单线程的方式执行事务,并且服务器保证,在执行事务期间不会对事务中断,因此,redis的事务总是以串行的方式运行,并且事务也总是具有隔离性的。

耐久性:Redis事务的耐久性由Redis所使用的持久化模式决定的,(不论Redis在什么模式下运行,在一个事务的最后加上SAVE命令总可以保证事务的耐久性。)

 


每天学一点,总会有收获。

 

说明:尊重作者知识产权,文中内容参考《Redis设计与实现》,仅在此做学习与大家分享。

 


 

 

内容来源于网络如有侵权请私信删除

文章来源: 博客园

原文链接: https://www.cnblogs.com/xtt321/p/13122183.html

你还没有登录,请先登录注册
  • 还没有人评论,欢迎说说您的想法!