趁着这段时间有点时间，把之前了解的零零散散的网络知识笔记都整理了一下，集中回顾一遍，加深一下印象。

网络方面的东西，我也是后面才去详细了解的，之前知道的都比较片面，对一些点知道的比较浅，也就对UDP、TCP了解的会稍微多一点，后面当我详细去了解的时候，我发现看完之后豁然开朗，就像表面上没改变什么，但实际上对上层的事了解的更多了，很玄妙的感觉。

软件架构大多数情况下不会影响我们将来上线产品，但糟糕的代码必然会堆积成山，由我们未来背负。这里我们首先要明白软件开发的两个难点：

技术难，代码量可能不多，但都是一些比较核心的需要攻坚型的问题，不是靠“堆人”就能搞定的，比如自动驾驶、图像识别、高性能消息队列等；

复杂度，意思是说，技术不难，但项目很庞大，业务复杂，代码量多，参与开发的人多，比如物流系统、财务系统等。

Frangipani: 一个可伸缩的分布式文件系统

摘要

理想的分布式文件系统应该为所有用户提供对同一组文件的一致的统一的访问，并且可以任意伸缩，以便为不断增长的用户社区提供更多的存储空间和更高的性能。尽管组件出现故障，但它仍然具有很高的可用性。这将需要最少的人工管理，并且随着添加更多组件，管理不会变得更加复杂。

论文理解

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。