原文链接

1.现状

1.1. 业务背景

（1）项目名称。

（2）业务描述。

1.2.技术背景

（1）架构描述。

（2）当前的系统容量：比如系统调用量的平均值，请求响应时间的平均值等。

（3）当前系统调用量峰值、最大、最小响应时间等。

原文链接

LRU-least recently used-最近最少使用算法，是一种内存数据淘汰策略，使用常见是当内存不足时，需要淘汰最近最少使用的数据。LRU常用语缓存系统的淘汰策略。

原文链接

上一期，简单的介绍了一下消息队列的基础知识，里面有消息队列的应用场景，以及使用之后可能带来的问题，但是上期没对怎么解决这些问题做回答，因为要控制篇幅嘛（明明是自己觉得MQ写不了多少期，要多怼一期出来！渣男）

摘要

map 通过 hasTable 实现了我们最常见的 key-value 存储，能快速的对数据集增删查改。同时 Go 里的 map 也有很多特殊的地方，比如它的无序性、并发不安全等。今天，就让我们对 map 进行深入研究，看看它是怎么设计的。

原文链接

Redis 总体介绍

Redis 是 key-value 型的 memory 缓存中间件，相信大部分程序员都在项目中使用过它。我们也可以利用 memory 来实现缓存，只是使用 redis 的话，可以将缓存功能统一到一个组件里，方便后续重用拓展。

原文链接

分布式系统的挑战

在前面的文章里，我们分析了分布式系统在业务上的一致性技术，即分布式事务，它的结果导向是面向用户的。然而在我们的系统内部，有时也需要面对来自软件架构等更高层次上的一致性要求，比如 Redis 的哨兵模式，Zookeeper 的选举过程等。它们所考虑的一致性更多的是服务节点之间一个共识 的达成，当共识达成之后，就可以以此为指导原则，展开更多的协同操作。

原文链接

现象

互联网的世界与十几年前相比，已经大不相同。以往的单体服务就可以支撑起大多数的用户需求。然而随着手机等电子产品的普及，用户想要的服务已经是越来越复杂，各种需求相互关联。而这也给软件开发带来了更多的挑战。为了应付随时会变化的代码世界，现有的开发趋势都在逐渐的化整为零。其中最具代表性的就是微服务的流行。

原文链接

一、怎么理解架构？

假如给你一个项目开发，你会怎么开始它？对于这个问题，我想很多猿友们都应该经历过吧。很多时候，我们会直接开干，让自己快速的进入 coding 状态。

然而一旦遇上稍微有点规模，比如涉及到多个业务功能的开发，那大概率会在开发过程中经常的怀疑自己，甚至产生推倒重来的想法；又或者眼看就要交付了，只能将错就错，修修补补。最后，一个让人揪心的系统又诞生了。