获得徽章 20
- #每天一个知识点# 数据一致性模型有哪些？
强一致性：当更新操作完成之后，任何多个后续进程的访问都会返回最新的更新过的值，这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。
弱一致性：系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。用户读到某一操作对系统数据的更新需要一段时间，我们称这段时间为“不一致性窗口”。
最终一致性：最终一致性是弱一致性的特例，强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。到达最终一致性的时间 ，就是不一致窗口时间，在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。最终一致性模型根据其提供的不同保证可以划分为更多的模型，包括因果一致性和会话一致性等。
因果一致性：要求有因果关系的操作顺序得到保证，非因果关系的操作顺序则无所谓。进程 A 在更新完某个数据项后通知了进程 B，那么进程 B 之后对该数据项的访问都应该能够获取到进程A 更新后的最新值，并且如果进程 B 要对该数据项进行更新操作的话，务必基于进程 A 更新后的最新值。
会话一致性：将对系统数据的访问过程框定在了一个会话当中，约定了系统能保证在同一个有效的会话中实现“读己之所写”的一致性，就是在你的一次访问中，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。实际开发中有分布式的 Session 一致性问题，可以认为是会话一致性的一个应用。展开等人赞过
评论4 - #每天一个知识点# 选举算法
waro：一种简单的副本控制协议，写操作时、只有当所有的副本都更新成功之后，这次写操作才算成功，否则视为失败。优先保证读、任何节点读到的数据都是最新数据，牺牲了更新服务的可用性、只要有一个副本宕机了，写服务就不会成功。但只要有一个节点存活、仍能提供读服务。
Quorum 机制：10个副本，一次成功更新了三个，那么至少需要读取八个副本的数据，可以保证读到了最新的数据。无法保证强一致性，也就是无法实现任何时刻任何用户或节点都可以读到最近一次成功提交的副本数据。需要配合一个获取最新成功提交的版本号的 metadata 服务，这样可以确定最新已经成功提交的版本号，然后从已经读到的数据中就可以确认最新写入的数据展开评论点赞 - #青训营 x 字节后端训练营# 今日学习《Go语言之网络编程》，主要讲述了Go语言中的网络编程。 关于网络编程是一个很庞大的领域，该文只是简单的演示了如何使用net包进行TCP和UDP通信。评论点赞
- #青训营 x 字节后端训练营# 今日学习《并发组件 | Go设计模式实战》，主要讲述了「组合模式」结合Go语言天生的并发特性，如何在真实业务场景中使用，结合Go语言天生的并发特性，升级「组合模式」为「并发组合模式」。评论点赞
- #青训营 x 字节后端训练营# 今日学习《如何用Go语言进行Web应用的开发？附4个常用框架对比总结！》，主要讲述了如何用Go语言进行Web应用的开发，并推荐了书籍 《Go Web 编 程实战》 ，书籍介绍如何用Go语言进行Web应用的开发。评论点赞