二手车为什么做网站网站开发有什么点子

当前位置： 首页 > news >正文

二手车为什么做网站,网站开发有什么点子,建立网站大概需要多少钱,wordpress 餐饮 主题数据一致性模型 根据一致性的强弱分类#xff0c;可以将一致性模型按以下顺序排列#xff1a; 强一致性 最终一致性 弱一致性 数据一致性模型一般用于分布式系统中#xff0c;目的是定义多个节点间的同步规范。 在这里#xff0c;我们将其引入数据库和缓存组…数据一致性模型 根据一致性的强弱分类可以将一致性模型按以下顺序排列 强一致性 最终一致性 弱一致性 数据一致性模型一般用于分布式系统中目的是定义多个节点间的同步规范。 在这里我们将其引入数据库和缓存组成的存储系统中在这个系统中数据库和缓存就是两个节点。 我们将尝试采用不同的方案实现这两个节点的同步状态。 此外由于 MySQL 和 Redis 的广泛流行我们这里可以把数据库 MySQL缓存 Redis。 强一致性模型 强一致性模型要求在分布式系统中所有节点对于某个数据项的值都是一致的。 即所有读操作总能返回最新的写操作结果。 强一致性模型可以通过使用共享内存、锁、原子操作等同步机制来实现。 最终一致性模型 允许在分布式系统中不同节点可能对于某个数据项的值是不一致的但是在某个时间点所有节点对于某个数据项的值都会达到一致。 即读操作不一定能返回最新的写操作结果。数据更新后不保证立即一致但保证在一定时间内最终一致。 最终一致性模型通常使用消息队列和事件源等异步机制来解决数据一致性问题。 弱一致性模型 弱一致性模型允许在分布式系统中不同节点可能对于某个数据项的值是不一致的。 弱一致性模型通常使用版本号(version number)和最近COMMIT时间戳等机制来解决数据一致性问题。 区别 强一致性与弱一致性的区别 强一致性要求在分布式系统中所有节点对于某个数据项的值是一致的。弱一致性允许在分布式系统中不同节点可能对于某个数据项的值是不一致的。强一致性可以通过使用共享内存、锁等同步机制来实现而弱一致性可以通过使用版本号、时间戳等机制来解决数据一致性问题。 最终一致性和弱一致性的区别 弱一致性允许在分布式系统中不同节点可能对于某个数据项的值是不一致的。最终一致性允许在分布式系统中不同节点可能对于某个数据项的值是不一致的但是在某个时间点所有节点对于某个数据项的值都会达到一致。最终一致性可以通过使用消息队列、事件源等异步机制来解决数据一致性问题。 强一致性模型适用于需要高度一致性的场景如银行转账、电子商务订单等。 弱一致性模型适用于需要高度可用性和扩展性的场景如缓存、数据备份等。 最终一致性模型适用于需要实时性和弹性的场景如实时数据分析、日志处理等。在选择数据一致性模型时需要权衡应用场景的一致性、可用性、扩展性和实时性需 数据库和缓存的数据一致性 - 过程一致性- 第一种不一致缓存和数据其中一者为空- 第二种不一致缓存和数据皆存在但值不同。- 先抛一下结论在满足实时性的条件下不存在同时保证过程一致性和最终一致性的方案 最好的结果是第一种过程不一致 最终一致性方案。 在满足实时性的前提下不存在强一致性的方案只有最终一致性方案。 事实上除了秒杀、余额交易等准确性要求高的业务外其它业务并不追求强一致性。 不好的方案每个请求都先写数据库再写缓存 例如 A请求在先更新数据为10B请求在后更新数据为11。最终数据库和缓存中的变量应该都为 11。 至少应有四步理想的顺序为 线程 A 执行 updateMySQL(10)。线程 A 执行 updateRedis(10)。线程 B 执行 updateMySQL(11)。线程 B 执行 updateRedis(11)。 然而As we all know进程并发执行其执行顺序并非固定。 理想的情况是 1234但1324也是可能的。 最坏的情况1342即下图 这种顺序下执行完四步最终数据库为 11缓存为 10。 不好的方案每个请求都先写 Redis再写 MS 与第一种方案出错的原因一致。
不好的方案每个请求都先删除 Redis再写 MS最后写 Redis 这种方法可以达到最终 一致性但可能由于过程不一致被并发线程脏读。 请求 A 是更新请求目标是将变量更新为 11 请求 B 是读请求 最初状态下MS 和 Redis 都为 10。 A请求第一步删除缓存。此时 MS 为 10缓存为空。B 查询变量的值但是由于未命中缓存查询 MS 得到 10。查询结果错误A请求第二步更新 MS 11。此时 MS 为 11缓存为空B 知道缓存中不存在但 MS 中有自然会写回 Redis此时 MS 为 11Redis 为 10。此时数据已经不一致了任意线程此时查询会查到错误的 10A请求第三步更新 Redis 11。此时 MS 为 11Redis 为 11。 【2】和【4】都是可能的脏读发生时机【2】发生的可能更大因为查询远快于更新。 好的方案【缓存双删】每个请求都先删除 Redis再写 MySQL再删除 Redis 这个方案是对 “先删除 Redis再写 MySQL” 的升级因为在后者存在最终一致性问题。 既然最终 MS 和 Redis 不一致那干脆把 Redis 重新删除即可这个也是大家常说的“缓存双删”。 A请求为更新请求目标是将变量更新为 11 B请求为读请求查询变量的值 最初状态下MS 和 Redis 都为 10。 A请求第一步删除 Redis 中的变量10。此时 MS 为 10 Redis 为空B 查询变量的值但是由于未命中缓存查询 MS 得到 10A请求第二步写 MS 为 11。此时 MS 为 11Redis 空B 知道缓存中不存在但 MS 中有自然会写回 Redis此时 MS 为 11Redis 为 10。A请求第三步删除 Redis 中的变量 10。此时 MS 为 11Redis 为 空。 【2】和【4】都是可能的脏读发生时机【2】发生的可能更大因为查询远快于更新。 尝试改进【延时双删】每个请求都先删除 Redis再写 MySQL再延时删除 Redis 回看上一个方案的蓝字部分– 即时序图的第四步、第五步。 需要注意第四步和第五步必须依次执行。 倘若先第五步 A请求第三步删除 Redis 中的变量 10。此时 MS 为 11Redis 为 空。 再第四步B 知道缓存中不存在但 MS 中有自然会写回 Redis此时 MS 为 11Redis 为 10。 连最终一致性也不能保证了这就是一个很坏的方案。 为了确保第四步第五步依次执行不妨在执行第五步前主动休眠 A请求一段时间以确保最后执行。 这就是延时的地方。 但也并非完美因为延时的时机如果掌控不好仍然会被脏读。 继续改进 使用消息队列 既然休眠总体第五步定时延时删除缓存不一定好用。 将这一步加入加入消息队列中执行异步串行化删除。
好的方案每个请求都先写 MS再删除 Redis 【2】是可能的脏读发生时机 此外在满足以下两个条件时这种方案还可能出现另一种意外 请求B开始查询时缓存刚好自动失效请求 B 从数据库查出 10回写缓存的耗时比请求 A 写数据库并且删除缓存的还长。 此时完全乱套了数据库中的是错误的数据。 但注意这种情况发生的条件之一是请求 B 从数据库查出 10 的耗时 请求B 回写缓存的耗时 请求 A 写数据库 请求A 删除缓存的耗时 不等式左右两边各有一次数据库 一次缓存但我们显然可知左边查数据库的耗时是远小于右边写数据库的耗时的 因此这一条件很难满足极端情况发生的概率很小。 先写 MySQL通过 Binlog异步更新 Redis 这种方案主要是监听 MySQL 的 Binlog然后通过异步的方式将数据更新到 Redis这种方案有个前提查询的请求不会回写 Redis。 这个方案会保证 MySQL 和 Redis 的最终一致性但是如果中途请求 B 需要查询数据如果缓存无数据就直接查 DB如果缓存有数据查询的数据也会存在不一致的情况。 所以这个方案是实现最终一致性的终极解决方案但是不能保证实时性。 定论 先写 Redis再写 MySQL 这种方案我肯定不会用万一 DB 挂了你把数据写到缓存DB 无数据这个是灾难性的 我之前也见同学这么用过如果写 DB 失败对 Redis 进行逆操作那如果逆操作失败呢是不是还要搞个重试 先写 MySQL再写 Redis 对于并发量、一致性要求不高的项目很多就是这么用的我之前也经常这么搞但是不建议这么做 当 Redis 瞬间不可用的情况需要报警出来然后线下处理。 先删除 Redis再写 MySQL 这种方式我还真没用过直接忽略吧。 先删除 Redis再写 MySQL再删除 Redis 这种方式虽然可行但是感觉好复杂还要搞个消息队列去异步删除 Redis。 先写 MySQL再删除 Redis 比较推荐这种方式删除 Redis 如果失败可以再多重试几次否则报警出来 这个方案是实时性中最好的方案在一些高并发场景中推荐这种。 先写 MySQL通过 Binlog异步更新 Redis 对于异地容灾、数据汇总等建议会用这种方式比如 binlog kafka数据的一致性也可以达到秒级 纯粹的高并发场景不建议用这种方案比如抢购、秒杀等。 个人结论 实时一致性方案采用“先写 MySQL再删除 Redis”的策略这种情况虽然也会存在两者不一致但是需要满足的条件有点苛刻所以是满足实时性条件下能尽量满足一致性的最优解。 最终一致性方案采用“先写 MySQL通过 Binlog异步更新 Redis”可以通过 Binlog结合消息队列异步更新 Redis是最终一致性的最优解。