1.1 还有哪些问题需要考虑?
每个模块的设计目标并不一样,在做这次重建之前,有一个至关重要的前提是,新建系统要兼容旧系统,那就意味着有些组件不能被替换掉,尤其是数据库部分。
哪些组件不能被替换掉呢?
- 数据库,目前用的mysql,如果你说我就要替换掉,那也不是不可能,但就是成本比较高,但又有什么理由去做一个费力不讨好的事儿呢?
- 数据库主键生成策略目前采用的是分布式id生成器,系统已经运行了好几年了,但我们目前的数据库表的记录不到100w,我真不知道当时为啥选择分布式id生成器,用主键不香吗?一般用分布式ID主要是分库分表,但我们目前的业务增长量好像近期也不需要分库分表啊。而且分布式id生成器需要进行网络通讯,万一网络抖动了导致无法生成主键id,那岂不是很麻烦?凡是依赖于网络的都存在不可靠的因素。
有哪些可以被替换掉的?
代码,代码还是代码,代码做好兼容性就好了,也许会费点时间,那又何妨,换来一个清爽的,简约的结构不爽吗?
2. 技术方案选型
先讲个故事,我有三个朋友,他们是大C,M,和小D。
大C做事情非常麻利从来不拖泥带水,交给他的事情他都能帮你办的妥妥的。
小D慢性子,社恐,但做事情非常仔细,循规蹈矩,不出格,你交给他的事情除了慢一点,没别的毛病。
M呢,和事佬,经常调节大C和小D之间的矛盾,大C总是嫌小D做事情拖拖拉拉,慢慢腾腾的,他们两个一旦有矛盾,M总会出现。
我这三个朋友他们分别是 CPU,Memory,Disk。
我偷偷的告诉你,后来大C觉得总是麻烦M,很不落忍,于是他经常把自己和小D的矛盾积攒在一起,然后一次性交给M来帮忙解决,积攒在一起的这个地方叫 L Cache。
如果要做到高性能,业内通常的做法是加缓存,在快和慢之间。
如果要做到高并发,那肯定不能一个人全把活干了,需要多个像CMD这样的组合,这就是横向扩展。
在上边的故事中,我们捋清楚了他们各自的角色,但有一点需要特别注意,小D的工作任务怎么能有条不紊的交给M呢,他们之间是不是得有条航线啊,这条航线叫操作系统。 万一这条航线断掉怎么办呢?
2.1 mysql和Redis如何保持一致性
说了半天,其实我想跟你探讨如果小D是mysql,M是Redis,怎么保证mysql和Redis的数据一致性呢,我调研了业内的一些做法,别嫌麻烦,看一看也许能让你年薪50w,当然也有可能100w,总之祝福你。
经典的缓存方式有三种:
-
read/write Through : 读/写直接操作缓存,如果缓存未命中,读/写把数据库数据加载到缓存。整个操作有缓存中间件去完成。
-
write behind :先写缓存,后写数据库,会带来不一致。
-
cache aside:
失效:应用程序从缓存中取,如果未命中,则从数据库中取,然后放到缓存。
命中: 缓存命中,直接取缓存中数据
更新:先更新数据库,然后让缓存失效。
根据cache aside的几种情况,详细拆解为以下几种情况。
ini
复制代码
策略1:先写数据库,后更新缓存 case1:数据库成功,缓存失败: 数据库值最新的,缓存值是旧的; 这将导致不一致。 解决方法:重试一直到缓存更新成功,在重试之前会存在短暂的不一致,但会最终一致。 case2:并发场景:: 线程A更改数据库FieldA=1,线程B更改数据库FeildA=2, 线程B对缓存的更改晚于线程A, 导致缓存结果是FieldA=1而数据库结果是FieldA=2 --不一致。 解决方法:数据按照更新的顺序同步到缓存,在更新到缓存之前会出现短暂的不一致,但最终会一致。 case3:大量更新操作 如果存在大量的更新操作会影响性能;会出现非热点数据长期在缓存中,浪费内存空间的问题。 解决方法:适用于低频的写操作;同时给缓存数据设置过期时间
css
复制代码
策略2:先写数据库,后删缓存 case1:数据库成功,缓存失败: 数据库值是最新的,缓存是旧值:-不一致。 解决方法:重试机制会最终一致,但在重试成功之前会有短暂的不一致。 case2:并发场景: 线程A更改FieldA=1,线程B更改FeildA=2, 线程B对缓存的更改晚于线程A; 不会出现不一致场景,此刻是缓存被删除了,最终数据一致 case3:并发场景: 读取FieldA,这个时候缓存恰好失效,线程A需要从数据库中读取数据,同时有个并发的写操作对FieldA进行更改, 数据库更新完成后,使缓存失效, 恰好这个时候读操作把旧值放到缓存,导致数据不一致。 解决方法:这种场景发生需要具备 读的速度要慢于写的速度并且有并发写操作下, 一般这种数据库读速度是远大于写的速度,这种事情发生的概率很小 case4:网络抖动 线程A更改FieldA=1,线程B更改FeildA=2;数据库目前最新值是FeildA=2, 由于网络抖动导致缓存未同步,读操作取的还是缓存旧值,等待网络恢复,缓存被删除。- 最终一致
复制代码
策略3:先写缓存,后写数据库 case1: 缓存成功,数据库失败:此时缓存的数据是脏数据
复制代码
策略4: 先删除缓存,后更新数据库 case1: 缓存成功,数据库失败:丢失新的请求
猜猜按照我们的业务场景,最终选择了哪一种呢?
奖券的修改属于读多写少的场景,同时写操作属于低频操作,并不会存在因大量更新导致的性能低下。
如果采用策略2,如果有大量缓存失效,那将会有大量请求分发到数据库中,导致数据库压力上升,目前在读多写少的场景中,希望更多的命中缓存的方式。
如果采用策略1需要解决的问题是:消息的顺序性;容忍短暂的不一致
通过调研canal在同步binlog的机制中可以按照顺序进行同步 在高并发场景中不会出现错误,所以在业务场景中,我们选择了策略1。