201911读书汇

2019-11-24 19:29:08

《细雨中呼喊》 状态:100% finished 个人评价:一般 一部上世纪的回忆类小说,描述了“我”周边发生的各种事情,有善,有恶,有美,有丑,有封建迷信,也有看似存在的因果报应,而这一切,都在余华的冷静朴实而凌厉的笔下,通过一个孩童的视角通通展示开来。

etcd raftexample源码浅析(1)

2019-09-30 14:31:31

最近在看etcd的相关源码,从简单的raftexample进行代码入手是一个不错的方案。相应代码入口在etcd-io/etcd/contrib/raftexample,建议可以先从github上将对应clone下来对照着来会好些。 raftexample大致流程图 我尝试用过先整理整个大概框架,然后再通过细分讲解里面具体模块的方式来说明这个服务的处理流程。 挑里面的重点,简单讲解下流程 这个示例中,我们Server支持PUT、GET、POST、DELETE共四种请求方式,分别对应的也是数据的更新和获取,配置的新增和删除; 步骤1、2,我们以其中的PUT方法展开说明,当收到client发送过来的数据更新或新建操作后,首先会调用我们的状态机(KVStore)向我们的通信管道(proposeC)发送数据; 步骤3,raftNode模块从管道proposeC中监听到有数据事件到来后会将该数据继续往下层模块node传递,node模块也算是我们raft协议里面实现的核心部分,在这个地方我们先记住它是预先对我们数据进行了一些简单处理。随后node模块会通过另外一个管道告知我们数据预处理好了; 步骤4,当raftNode收到从nkvode模块传递上来的准备就绪信息后就开始进行余下的操作,如wal日志写入-->更新raft示例的内存状态-->通过广播的形式将自己收到的消息发送给集群其它peer-->更新自身状态机-->触发快照-->告知底层node我已处理完成,可以发送下一个消息. 提前感知的结构体 这里提前感知两个结构体kvstore,raftNode,

Etcd raft 原理动画演示

2019-09-03 18:23:45

http://thesecretlivesofdata.com/raft/

201908读书汇

2019-08-29 22:56:05

《人世间》 状态:100% finished 个人评价:力荐 偶然机会看到了这本书,第十届茅盾文学奖的作品之一,正好《中国之声》在推荐,遂看之。 一部115w字的知青类小说,从改革开放到2016年,跨越了整整五十年,往往很多人评价,这是一部适合五六十年代的人看的书,因为他们能产生更多的共鸣。没想到我竟会迷上,酒香不怕巷子深嘛,哈哈。梁晓声写这部作品是带了感情的,对特殊年代、动荡岁月的全景描述,整个人物的刻画是很容易把我带入其中的。书中没有很多明目张胆教书育人的做法,但是看完后却能让你不由自主的去思考。正如有人的评价:无论哪个国家,为什么名著多处于社会动荡的岁月?因为动荡岁月中的人,生活是跌宕的,经历是丰富的,感情是被熬炼过的。 对于这个评价,甚是认同! 多说一句,同类知青小说,看过余华的几部,但是余华更多的是带有对现实世界的批判,梁晓声的更多的带有叙事性,但是充满感情的那种,同个时代完全两种风格的人。

MySQL配置文件my.cnf查找

2019-07-18 15:32:44

常常因为想看一下MySQL里面的配置my.cnf,却苦于找不到这个文件的存放位置。下面是常用的三个查找方法,快准狠! ps 利用ps命令。mysql启动时往往携带很多启动参数,看看是否有启动指定的配置文件,命令如下: ps aux|grep mysql 命令 ps aux|grep mysql|grep 'my.cnf' 输出 fdipzone 25174 0.0 0.0 3087244 600 ?? S 4:12下午 0:01.14 /usr/local/Cellar/mysql/5.6.24/bin/mysqld --defaults-file=/usr/local/Cellar/

06 | 全局锁和表锁:给表加个字段怎么有那么多阻碍?

2019-07-15 10:01:43

本文的总结源于林晓斌在极客时间里面的课程,为避免产生商业问题,我只是用于个人学习总结。 原文地址:https://time.geekbang.org/column/article/69862 小结 根据加锁范围:MySQL里面的锁可以分为:全局锁、表级锁、行级锁 全局锁 对整个数据库实例加锁 MySQL提供全局读锁的方法:flush tables with read lock(FTWRL) 这个命令可以使整个库处于只读状态,使用该命令之后,数据更新语句、数据定义语句和更新类事务的提交语句等操作都会被阻塞。 使用场景:全库逻辑备份 风险: 如果在主库备份,在备份期间不能更新,业务停摆 如果在从库备份,备份期间不能执行主库同步的binlog,导致主从延迟 官方自带的逻辑备份工具Mysqldump,当Mysqldump使用参数--single-transaction的时候,会启动一个书屋,确保拿到一致性视图。而由于MVCC的支持,这个过程中数据是可以正常更新的。 一致性读是好,但是前提是引擎要支持这个隔离级别。 如果要全库只读,为什么不使用set global

05 | 深入浅出索引(下)

2019-07-12 15:49:03

本文的总结源于林晓斌在极客时间里面的课程,为避免产生商业问题,我只是用于个人学习总结。 原文地址:https://time.geekbang.org/column/article/69636 小结 覆盖索引:覆盖索引可以减少树的搜索次数,显著提升查询性能,所以使用覆盖索引是一个常用的性能优化手段 针对某些高频查询,要根据市民的身份证号查询他的姓名,则在(身份证号、姓名)上面创建一个联合索引,就可以在这个高频请求上用到覆盖索引,不再需要回表查整行记录,减少语句的执行时间 B+树这种索引结构,可以利用索引的“最左前缀”,来定位记录 联合索引的理解:比如一个联合索引(a,b,c),其实质是按a,b,c的顺序拼接成了一个二进制字节数组,索引记录是按该字节数组逐字节比较排序的,所以其是先按a排序,再按b排序,再按c排序,至于其为什么是按最左前缀匹配的也就显而易见了。 给表创建索引时,应该创建哪些索引,每个索引应该包含哪些字段,字段的顺序怎么排列,这个问题没有标准答案,需要根据具体的业务来做权衡。不过有些思路还是可供参考的:

04 | 深入浅出索引(上)

2019-07-10 14:56:06

本文的总结源于林晓斌在极客时间里面的课程,为避免产生商业问题,我只是用于个人学习总结。 原文地址:https://time.geekbang.org/column/article/69236 小结 索引的作用:提高数据查询效率 常见索引模型:哈希表、有序数组、搜索树 哈希表:键-值(key-value) 哈希思路:把值放在数组里,用一个哈希函数把key换算成一个确定的位置,然后把value放在数组的这个位置 哈希冲突的处理办法:链表 哈希表适用场景:只有等值查询的场景 有序数组:按顺序存储。查询用二分法就可以快速查询,时间复杂度是:O(log(N)) 有序数组查询效率高,更新效率低 有序数组的适用场景:静态存储引擎(比如往年数据,不会进行变动的数据) 二叉搜索树:每个节点的左儿子小于父节点,父节点又小于右儿子 二叉搜索树:查询时间复杂度O(log(N)),更新时间复杂度O(

03 | 事务隔离:为什么你改了我还看不见?

2019-07-09 16:54:24

本文的总结源于林晓斌在极客时间里面的课程,为避免产生商业问题,我只是用于个人学习总结。 原文地址:https://time.geekbang.org/column/article/68963 思维导图 图形解说 针对上面看到的四个隔离级别,并结合这个案例来进行解说,我们来看看不同的隔离级别下,事务A会有哪些不同的返回结果,也就是图里面V1、V2、V3的返回值分别是什么 若隔离级别是“读未提交”,则V1的值就是2.这时候事务B虽然还没有提交,但是结果已经被A看到了。因此,V2、V3也都是2. 若隔离级别是“读提交”,则V1是1,V2的值是2.事务B的更新在提交后才能被A看到。所以V3的值也是2. 若隔离级别是“可重复读”,则V1、V2是1,V3是2.之所以V2还是1,遵循的就是这个要求:事务在执行期间看到的数据前后必须是一致的。 若隔离级别是“串行化”,则在事务B执行“将1改成2”的时候,会被锁住。直到事务A提交后,事务B才可以继续执行。

02 | 日志系统:一条SQL更新语句是如何执行的?

2019-07-09 16:10:49

本文的总结源于林晓斌在极客时间里面的课程,为避免产生商业问题,我只是用于个人学习总结。 原文地址:https://time.geekbang.org/column/article/68633 本篇重点 一条SQL语句的执行步骤 update T set c=c+1 where ID=2; 执行流程图 小结 redo是物理的,binlog是逻辑的;现在由于redo是属于InnoDB引擎,所以必须要有binlog,因为你可以使用别的引擎 保证数据库的一致性,必须要保证2份日志一致,使用的2阶段式提交;其实感觉像事务,不是成功就是失败,不能让中间环节出现,也就是一个成功,一个失败 如果有一天mysql只有InnoDB引擎了,有redo来实现复制,那么感觉oracle的DG就诞生了,物理的速度也将远超逻辑的,毕竟只记录了改动向量 binlog几大模式,一般采用row,因为遇到时间,从库可能会出现不一致的情况,但是row更新前后都有,会导致日志变大 最后2个参数,保证事务成功,