KIDO BLOG

Do not fear the unknown.

缓存与数据库一致性系列-04

经过前三篇的讨论，我们终于的实现了“最终一致性”，那今天呢，我们再进一步，在前一个方案的基础上实现“强一致性” 强一致性，包含两种含义：缓存和DB数据一致缓存中没有数据（或者说：不会去读缓存中的老版本数据）首先我们来分析一下，既然已经实现了“最终一致性”，那它和“强一致性”的区别是什么呢？没错，就是“时间差”，所以： “最终一致性方案” + “时间差” = “强一致......

Posted by Kido on 2018-12-09

缓存与数据库一致性系列-03

经过前两篇的讨论，我们离实现“最终一致性”只差一步了在《缓存与数据库一致性系列-02》文章，我们提到上一个方案的并发问题读的时候，缓存中的数据已失效，此时又发生了更新数据更新的时候，缓存中的数据已失效，此时又发生了更新那我们我们可以看到，这个问题就来自于“读数据库” + “写缓存” 之间的交错并发，那怎么来避免呢？有一个方法就是：串行化，我们利用MQ将所有“读数据库” + “......

Posted by Kido on 2018-12-08

缓存与数据库一致性系列-02

在《缓存与数据库一致性系列-01》文章，我们提到，“它的一个比较大的缺陷在于刷新缓存有可能会失败，而失败之后缓存中数据就一直会处于错误状态，所以它并不能保证数据的最终一致性” 为了保证“数据最终一致性”，我们引入binlog，通过解析binlog来刷新缓存，这样即使刷新失败，依然可以进行日志回放，再次刷新缓存写流程：第一步先删除缓存，删除之后再更新DB，我们监听从库(资源少的话主库也o......

Posted by Kido on 2018-12-07

缓存与数据库一致性系列-01

今天，我们来分析一下，缓存与数据库被使用次数最多的一种使用方法写流程：第一步先删除缓存，删除之后再更新DB，之后再异步将数据刷回缓存读流程：第一步先读缓存，如果缓存没读到，则去读DB，之后再异步将数据刷回缓存方案分析优点剖析1. 实现起来简单 What Should I Say ? 2. “先淘汰缓存，再写数据库” 合理为什么说这也算优点呢？试想一下如果把写流程改一下：先更新缓......

Posted by Kido on 2018-12-01

缓存与数据库一致性系列-序言

一般来说，对于一个新的业务，一般会经历这几个阶段：阶段1：单库阶段读写流量都比较小，这个时候所有的读写操作都在主库就ok了这个时候，从库可能只是用来灾备风险分析：从数据一致性角度来说没有风险，全走主库美滋滋~ 阶段2：多库阶段阶段2.1：单库扛不住了，这个时候就会考虑到分库分表了，通过增加数据库的方式，把单库的QPS降下来风险分析：从数据一致性角度来说没有风险，全走主库依然美滋滋~ 阶段......

Posted by Kido on 2018-11-24

浅谈JSON类库

1.JSON介绍JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式，易于人阅读和编写，同时也易于机器解析和生成，它基于JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一个子集。 JSON采用完全独立于语言的文本格式，这些特性使JSON成为理......

Posted by Kido on 2018-11-23

浅谈Redis事务

Redis事务和传统关系数据库事务的区别传统数据库事务过程在关系型数据库中，我们开启事务并进行一系列的读写操作，最后，用户用户可以选择发送commit来确认之前的修改，或者发送rollback来放弃之前的修改。 1234567891011Connection conn = ... //获取数据库连接conn.setAutoCommit(false); //开启事务try{ //......

Posted by Kido on 2018-11-17

-->