​ Zookeeper是一个分布式协调服务，可以用于元数据管理、分布式锁、分布式协调、发布订阅、服务命名等等。拥有一定的数据存储和查询能力，可以让我们在现在都是分布式部署的应用之间“传递”数据，其次 ZK 支持的回调通知，让应用可以在一些业务场景中感知到数据的变化并及时作出相应的反应。最后，ZK 本身也支持集群部署具有高可用的特点，是一个可靠的第三方中间件。这篇文章主要通过以下几个方面介绍Zookeeper：

​ 由于目前几乎很多大型网站或者应用都是采用分布式部署的，那么如何保证数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。”所以，很多系统在设计之初就要对这三者做出取舍。那么在绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。保证数据的最终一致性可以通过分布式事务、分布式锁来实现，这篇文章就来描述分布式锁的三种实现方式，这三种实现方式分别为：

​ 互联网三高背景下，如何保证 redis 的高并发和高可用？一般通过redis 的主从架构和redis 的集群模式。redis 单机能承载多高的并发？如果单机扛不住如何扛更多的并发？如何保证redis 的高可用不至于挂掉？这些都是这篇文章讨论的问题：

​ 只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么双写一致性问题如何解决？如果多客户端同时并发写一个 key，可能本来应该先到的数据后到了，导致数据版本错了；或者是多客户端同时获取一个 key，修改值之后再写回去，只要顺序错了，数据就错了？那么多客户端就会产生并发问题，那么Redis的并发问题如何解决？下面我们就通过以下几点来了解双写一致性问题。

想必大家在面试的时候问到redis的时候基本会被问到缓存的雪崩、穿透和击穿问题。那么接下来我们来了解什么是 Redis 的雪崩、穿透和击穿。Redis 崩溃之后会产生什么情况？系统该如何应对这种情况？如何处理 Redis 的穿透？这篇文章分为以下几个知识点：

上面我们了解过Redis的基本数据类型和线程模型之后，对Redis有个基本的了解，下面我们来了解下Redis的持久化策略和淘汰策略，通过这篇文章我们可以了解到：

缓存是现在几乎所有项目都会用到的技术，起到了对抗高可用高并发的作用。那么缓存在项目中的使用目的、使用场景、使用中要注意的问题有哪些呢？之后的redis系列，会一一阐述这些问题。第一篇文章从最基础的redis的数据类型和 使用场景说起，这篇文章主要描述以下内容：

AOP(Aspect Oriented Programming)：面向切面编程。AOP是在我们原来写的代码的基础上，进行一定的包装，比如在方法执行前、方法返回后、方法抛出异常后等地方进行一定的拦截处理或者增强处理。面向对象的编程核心模块是类，然而在AOP中核心模块是切面。切面实现了多种类型和对象的模块化管理，比如事物的管理、权限控制。通过这边文章，我们可以了解到以下几点：

​ 说到负载均衡，很多人可能第一个想到的就是Nginx和Spring Cloud Ribbon,但是对于服务端的更多熟悉的是Nginx，今天我们站在开发者的角度来稍微详细的介绍下Nginx，通过这篇文章，我们可以了解到：

看过HeadFirst设计模式的同学，应该印象比较深刻的本书第一个拿出来讲的就是策略模式，可以见得策略模式是比较适合入门的设计模式之一，那么今天我们就来详细说下设计模式之策略模式，通过这篇文章，我们可以了解到：