原文链接

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

摘要

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

原文链接

Redis 总体介绍

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

原文链接

分布式系统的挑战

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

原文链接

现象

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

原文链接

一、怎么理解架构？

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

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

原文链接

摘要

作为技术方案最常提到的组件：消息队列，它在我们的程序中起到了重要的作用。异步、解耦、削峰（缓冲）等特性正是我们选择它的原因。本文将会按自己的理解聊一聊消息队列的本质、使用场景、注意事项、以及介绍下主流的消息队列。

原文链接

前言

channel 是 goroutine 与 goroutine 之间通信的重要桥梁，借助 channel，我们能很轻易的写出一个多协程通信程序。今天，我们就来看看这个 channel 的常用用法以及底层原理。

一、channel 的概念

channel 是一个通道，用于端到端的数据传输，这有点像我们平常使用的消息队列，只不过 channel 的发送方和接受方是 goroutine 对象，属于内存级别的通信。