可这样表示：

相应代码代码：

size 是固定值，可以进行相应的改进：

**依赖注入设计思路**：

先设计行李箱的大概样子，再根据行李箱的样子设计箱体，根据箱体去设计底盘，然后去设计轮子。

相应代码如下：

不难理解，依赖注入就是**将底层类作为参数传递给上层类，实现上层对下层的控制**。

依赖倒置原则、IoC、DI 和 IoC 容器的关系：

补充：[控制反转-知乎解答](https://www.zhihu.com/question/23277575/answer/169698662)

- Resource 定位：即 BeanDefinition 的资源定位，Resource 为各种形式的 BeanDefinition 的使用都提供了统一的接口

- BeanDefinition 的载入

- 向 IoC 容器中注册 BeanDefinition：实际上 IoC 容器内部维护一个 HashMap，注册过程就是将 BeanDefinition 添加至 HashMap 中。

IoC 容器其实就是一个大工厂，它用来管理我们所有的对象以及依赖关系：

Spring bean 的生命周期执行如下图：

1、Spring 对 Bean 进行实例化。

原理图如下：

- 客户端发起 HTTP 请求，将请求提交到 DispatcherServlet。

- 寻找处理器：由 DispatcherServlet 查询一个或多个 HandlerMapping，找到处理该请求的 Contoller。

- MappedStatement 对 SQL 执行输出结果进行定义，包括 HashMap、基本类型、pojo，Executor 通过MappedStatement 在执行 SQL 后将输出结果映射至 Java对象中，输出结果映射过程相当于 jdbc 编程中对结果的解析处理过程。

MyBatis 的缓存分为一级缓存和二级缓存。默认情况下一级缓存是开启的。

每个节点还可以拥有 N 个子节点，最上层是根节点以“/”来代表，Zookeeper 的数据模型如下图：

Zookeeper 是一个基于主从复制的高可用集群。通常 3 台服务器就可构成一个 ZooKeeper 集群。ZooKeeper 官方提供的架构图就是一个 ZooKeeper 集群整体对外提供服务。

每一个 Server 代表一个安装 ZooKeeper 服务的服务器，组成 ZooKeeper 服务的服务器都会在内存中维护当前的服务器状态，并且每台服务器之间都互相保持着通信。

Zookeeper 集群在运行过程中需要支持更多的客户端并发操作，就需要更多的服务实例，而更多的服务实例会使集群投票阶段变得复杂，集群选主时间过程，不利于集群故障快速恢复。因此，Zookeeper 中引入 Observer，Observer 不参与投票，但是接收来自客户端的连接并响应客户端的读请求，将写请求转发给 Leader。加入更多的 Observer节点，不仅提高了 Zookeeper 集群的吞吐量，也保障了系统的稳定性。

S5 提议自己为 Leader 并为自己投票，然后与 S1、S2、S3和 S4 交换投票结果，发现 S3 已经成为 Leader，S5 就成为 Follower。