这几天瞎逛，不知道在哪里瞟到了缓存的双写，就突然想起来这块虽然简单，但是细节上还是有足够多我们可以去关注的点。这篇文章就来详细聊聊双写一致性。

之前的文章把 InnoDB 中的所有的锁都介绍了一下，包括意向锁、记录锁...自增锁巴拉巴拉的。但是后面我自己回过头去看的时候发现，对自增锁的介绍居然才短短的一段。

你在商场的卫生间上厕所，此时你一定会做的操作是啥？锁门。如果不锁门，上厕所上着上着，啪一下门就被打开了，可能大概也许似乎貌似有那么一丁点的不太合适。

索引是什么？为什么要有mysql 索引，解决了什么问题，其底层的原理是什么？为什么使用B+树做为解决方案？用其他的像哈希索引或者B树不行吗？

之前的文章Zookeeper基础原理&应用场景详解中将Zookeeper的基本原理及其应用场景做了一个详细的介绍，虽然介绍了其底层的存储原理、如何使用Zookeeper来实现分布式锁。但是我认为这样也仅仅只是了解了Zookeeper的一点皮毛而已。所以这篇文章就给大家详细聊聊Zookeeper的核心底层原理。不太熟悉Zookeeper的可以回过头...

例如，Kafka中就是用Zookeeper来保存其集群中的相关元数据，例如Broker、Topic以及Partition等等。同时，基于Zookeeper的Watch监听机制，还可以用其实现发布、订阅的功能。

Topic是一类消息的集合，是一种逻辑上的分区。为什么说是逻辑分区呢？因为最终数据是存储到Broker上的，而且为了满足高可用，采用了分布式的存储。

在之前的文章「简单了解InnoDB底层原理」聊了一下MySQL的Buffer Pool。这里再简单提一嘴，Buffer Pool是MySQL内存结构中十分核心的一个组成，你可以先把它想象成一个黑盒子。

这种方式与Redis的主从复制的思路没有太大的出入。如果你对Redis的主从复制感兴趣可以去看看《Redis的主从复制》。那既然Redis和MySQL都采用了复制这种方式，主从复制所带来的意义是什么呢？

上文我们聊了基于Sentinel的Redis高可用架构，了解了Redis基于读写分离的主从架构，同时也知道当Redis的master发生故障之后，Sentinel集群是如何执行failover的，以及其执行failover的原理是什么。

虽然说单机的Redis性能很好，也有完备的持久化机制，那如果你的业务体量真的很大，超过了单机能够承载的上限了怎么办？不做任何处理的话Redis挂了怎么办？带着这个问题开始我们今天的主题-Redis高可用，由于篇幅原因，本章就只聊聊主从复制。

我们知道虽然单机的Redis虽然性能十分的出色， 单机能够扛住10w的QPS，这是得益于其基于内存的快速读写操作，那如果某个时间Redis突然挂了怎么办？我们需要一种持久化的机制，来保存内存中的数据，否则数据就会直接丢失。

这是一个系列的文章，打算把Redis的基础数据结构、高级数据结构、持久化的方式以及高可用的方式都讲一遍，公众号会比其他的平台提前更新，感兴趣的可以提前关注，「SH的全栈笔记」，下面开始正文。

这篇博客的本意是希望看到这篇文章的读者能够很轻松的理解我想表达的意思。但程序向的分享经常会不经意间就贴上了代码，很可能就会让人看的很懵。而且我认为分享一个东西，只有对方真正明白了其中的逻辑，才是有意义的分享。所以接下来我会尝试用大家都能理解的语言来聊一聊”微服务“。

很多文章都是直接开始介绍有哪些存储引擎，并没有去介绍存储引擎本身。那么究竟什么是存储引擎？不知道大家有没有想过，MySQL是如何存储我们丢进去的数据的？

简单的介绍一下JVM（Java Virtual Machine）吧，它也叫Java虚拟机。虽然它叫虚拟机，但是实际上不是我们所理解的虚拟机，它更像操作系统中的一个进程。JVM屏蔽了各个操作系统底层的相关的东西，Java程序只需要生成对应的字节码文件，然后由JVM来负责解释运行。

在上一篇文章【简单了解系列】从基础的使用来深挖HashMap里，我从最基础的使用中介绍了HashMap，大致是JDK1.7和1.8中底层实现的变化，和介绍了为什么在多线程下可能会造成死循环，扩容机制是什么样的。感兴趣的可以先看看。

说的专业一点，HashMap是常用的用于存储key-value键值对数据的一个集合，底层是基于对Map的接口实现。每一个键值对又叫Entry，这些Entry分散的存储在一个由数组和链表组成的集合中。当然在Java8中，Entry变成了Node。

TCP，全称Transmission Control Protocol，是一种面向连接、可靠的、基于字节流的单播协议。与我们常说的TCP/IP协议不同，TCP/IP是一个协议族，涉及到OSI模型中的网络层、应用层和应用层。而我们要聊的TCP就是在传输层的协议，现在应用的特别广泛的HTTP请求，就是基于TCP的。

Nothing is true. Everything is permitted. 写在前面 先聊聊为什么想到了要用Vuepress来代替原来写在Confluence上的文档。 大意是有个需要其他部门接入的项目，这个项目有个用md写的接入文档，其他部门的人需要看着这个文档才知道怎么接以及哪些东西需要接。 但是有个问题是这个文档长的一匹，有多长呢？ 而且这个md文...

距离上次更新已经有一个月了，主要是最近工作上的变动有点频繁，现在才暂时稳定下来。这篇博客的本意是带大家从零开始搭建K8S集群的。但是我后面一想，如果是我看了这篇文章，会收获什么？就是跟着步骤一步一走吗？是我的话我会选择拒绝，所以我加了关于K8S的简单介绍，每一步的步骤都添加了解释。由于篇幅和时间原因，...

然后随便搜了一下关于Go继承的文章，发现有的文章的代码量过多，并且代码format极其粗糙，命名极其随意，类似于A、B这种，让人看着看着就忘了到底是谁继承谁，我又要回去看一遍逻辑。

用Go语言写游戏服务器也有一个多月了，也能够明显的感受到两者的区别。这篇文章就是想具体的聊聊其中的区别。当然，在了解区别之间，我们先简单的了解一下Go语言本身。

你会发现结果仍然是一样的。简单的推理一下我们就能知道，在上面那种情况，每次都取到相同的随机数跟我们所取的样本空间大小是无关的。那么唯一有关的就是seed。我们首先得明确seed的用途。

我认为我还是有必要把这个比较重要的节点记录下来，我也是第一次在自己的博客里面写这种偏阅读非技术类的文章，虽然没有技术细节，却又与技术息息相关。

选择排序（Selection sort）是一种简单直观的排序算法。它的工作原理如下。首先在未排序序列中找到最小（大）元素，存放到排序序列的起始位置，然后，再从剩余未排序元素中继续寻找最小（大）元素，然后放到已排序序列的末尾。以此类推，直到所有元素均排序完毕。

这篇文章包含了你一定知道的，和你不一定知道的冒泡排序。 gif看不了可以点击【原文】查看gif。 源码: 【地址】 1. 什么是冒泡排序 可能对于大多数的人来说比如我，接触的第一个算法就是冒泡排序。 我看过的很多的文章都把冒泡排序描述成我们喝的汽水，底部不停的有二氧化碳的气泡往上冒，还有描述成鱼吐泡泡，都特别的...

这个概念其实有些广泛，而我的知识广度也有限，我会尽量用通俗的语言来描述什么是微服务，什么是集群，以及为什么我们需要微服务集群 。为什么需要集群可以去看看《小强开饭店-从单体应用到微服务》，这篇文章用非常通俗的语言和配图，通过一个漫画故事简单的解释了为什么我们需要微服务集群。

Println函数接受参数a，其类型为…interface{}。用过Java的对这个应该比较熟悉，Java中也有…的用法。其作用是传入可变的参数，而interface{}类似于Java中的Object，代表任何类型。

本篇博客通过小强开饭店的通俗易懂的故事，带你了解后端服务是如果从单体应用演变到微服务的。如果有说的不对的地方，欢迎各位大佬强势怼。 小强开饭店 有一天，小强为了早日奔赴小康生活，打算开一个饭店来帮他快速的实现这个目标。 饭店开业了 于是他盘下了一个店面，一顿装修之后，雇了一个厨师，便开业了。 饭店生意...