Amazon Aurora以及ZK论文学习
论文理解
ZK的论文里面的东西感觉很多都是和ETCD相似的,之前也写过ZK的一些不同的点,原理上,毕竟其也是基于raft协议的,操作上相似感觉比较合理。
Aurora,这里面还是有很多东西的,不管是基于MySQL的改造(canal搬运log感觉很像),另外还有quorum因地制宜的使用,数据库服务与存储层服务的分层设计,简化副本复制,采用链式复制等,对这种大型服务的设计能力可见一斑。
ZK的论文里面的东西感觉很多都是和ETCD相似的,之前也写过ZK的一些不同的点,原理上,毕竟其也是基于raft协议的,操作上相似感觉比较合理。
Aurora,这里面还是有很多东西的,不管是基于MySQL的改造(canal搬运log感觉很像),另外还有quorum因地制宜的使用,数据库服务与存储层服务的分层设计,简化副本复制,采用链式复制等,对这种大型服务的设计能力可见一斑。
因为有个业务需要算周别,且是按照周天到周六的算法,和常见的周一到周天,有些区别,所以ISOWeek
函数就不好使了,找了下发现Go没有现成的,也没人实现过,所以就有了这篇文章。
内部一直需要使用消息队列,所以这边考虑写一个中间件简化这些代码交互,将交互统统归化统一为单纯的发送/接受处理函数。最近也算是完成了中间件CS端的编写了。
消息中间件的作用是为了简化应用程序对消息队列的交互,让应用程序更多的关心代码逻辑,不用关心Kafka
的操作。兼容Redis
协议,可以更为方便去掉写客户端的麻烦事(可以使用Redis
客户端,后面会提)。
正常项目中,对外提供的接口都是HTTP接口,可是后端架构中,我们内部已经迭代成gRPC版本了。这样还得做一层抽象HTTP层去调用server端的GRPC,在项目中,能免去这个HTTP层吗?
答案是可以的,使用网关,通过网关层做掉HTTP转GRPC的协议这层,这样就可以尽量让后端都提供出grpc了。
最近在项目中要考虑一个接口幂等问题,幂等既是,多次请求请求接口,接口操作的东西都不会被其后续的重复请求所改变,维持第一次请求成功时的样子。
例如查询操作,不管查询多少次,在数据不变的情况下,查询到的数据都是一样的;删除一条数据也是,删一次和多次,都已经将数据删除了。
流水线模型在编程中是非常常见的,但扇入扇出模型可能就较少听闻了。
以汽车组装为例,汽车生产线上有个阶段是给小汽车装4个轮子,可以把这个阶段任务交给4个人同时去做,这4个人把轮子都装完后,再把汽车移动到生产线下一个阶段。(这是流水线)
这个过程中,就有任务的分发,和任务结果的收集。其中任务分发是FAN-OUT,任务收集是FAN-IN。
Cache Aside 模型中,读缓存 Miss 的回填操作,和修改数据同步更新缓存,包括消息队列的异步补偿缓存,都无法满足 “Happens Before”,会存在相互覆盖的情况。