互联网两年多的思考，希望能和各位探讨。

http请求应该首先打在堡垒主机的Nginx(运行docker拉取的镜像，还需要指定挂载的配置文件，容器运行时会读取这些配置文件，就像是JAVA类中属性设置初始值，方法调用时可以访问该属性)上然后基于某种随机轮询或客户端地址hash的方式请求落在springboot内置的tomcat上面(在这个过程中优先执行过滤器的一些操作)，提供该web服务应该是运行的jar或者war包.web服务将注入eureka注册中心提供的来自各分布式节点提供的微服务。如果是dubbo则使用zk注册中心提供的来自各分布式节点提供的微服务。控制层一般作为服务消费者调用注册中心的服务，响应页面过来的请求，服务提供者一般是连接了数据库的jar包。

前后端数据交互使用http请求做json数据交互基本足够了，一些文档流类型的传输可以使用mongodb提供副本集群上传下载文档流的服务。做分布式缓存使用redis提供相应的服务(是否需要使用集群模式？分布式大牛与redis设计者何去何从)。分布式事务解决方案可以设计并使用本地消息表或者使用消息中间件。使用spring整合各种中间件都是一贯的料性(配置相关中间件的套接字访问方式)。 微服务读取套接字地址使用springcould的配置中心或者zk提供的配置文件读取方式均可。配置文件和源码应该在git库分别创建不同的文件夹用于分离。jekins构建各个模块的jar包和本地maven install 差不多，不过本地构建jar包在本地maven库，jekins则一般指定了远程git代码库和远程maven私库。springcould的配置中心需要提供有消息中间件的套接字访问方式。docker运行rabbitmq镜像提供rabbitmq的套接字访问方式。docker有个好处就是不需要关注erlong的安装。docker运行mysql镜像作为容器运行并没有使用数据卷volume时产生的数据会丢失。而数据卷volume的学习需要花费一定的精力。花费更多精力的应该是docker提供中间件集群服务，比如如何提供nginx的lvs反向代理服务，如何提供redis集群的套接字访问方式，如何提供rabbitmq集群的套接字访问方式(虽然我知道这个有直接的集群镜像)，如何提供zookeeper集群的套接字访问方式。(docker-compose或是k8s？)传统的物理集群至少应该打通各节点间的免密登录ssh 用户及其权限模块单点登录使用redis？ 流程审核模块使用activiti工作流？ 线程异步处理使用quartz？ 以前我认为使用spring整合中间件并掌握中间件的常用api就已经把spring玩的一溜一溜的，后来我发现手动扫包 并对包下的接口生成动态代理对象注入spring容器并为容器中不同的代理对象注入属性才能获得一些成就感。

基于多份数据带来的思考，数据备份往往消耗网络带宽，并在这备份的过程中，如果要保证主从一致，那么就必须保证从节点成功处理主节点下发的任务并告知主节点，主节点才算成功，主节点漫长等待从节点的回应能增加数据的安全性却让用户感到不耐烦，通常的做法是记个日志然后从节点异步处理，这时候如果异步到从节点失败，那么主从数据就会不一致。zk 使用paxos算法可以保证强一致。一些普通的选举算法并不附带强一致功能，而是通过一些网络流畅度的因素选举出主节点。根据不同的场景权衡是需要强一致还是高可用。

NIO可以看作IO密集型时对cpu极限压榨。

常用的多线程设计如下: 需要一个队列，请求消息写入队列，队列需要提供一个监听机制能够从一个给定的线程池中获取一个线程用于处理请求。或者给定的线程池不断轮询领取队列中的消息，取出消息作为参数执行响应的逻辑。

红黑树只有两个子节点所以树的的高度会比较大，适用于纯内存操作，不和磁盘交互，所以树深度对查询效率的影响微不足道。B树相比B+树的特点是B树非叶子节点也携带数据，两者相比红黑树分叉更多，假设分别有20G的结构化数据和文档流数据，可以直观的感受到文档流类型的key会比较少，因key量相对较少，程序局部性原理相对索引的区分度显得更重要，mongodb用B树实现有较大概率从内存直接获取数据(磁盘预读+使用合适的页面淘汰算法)。mysql因key量大，从内存中一次性就命中想要的数据不太现实，此时索引的区分度相对程序局部性原理显得更重要，B+树非叶子节点因不携带数据而使内存页存储更多区分度数据。所以mongodb索引使用B树结构，而mysql索引使用B+树

为什么是三次握手四次挥手？ 系统设计应遵循简单性原则，能两次解决问题就不三次，能三次解决就不四次。 客户端向web服务器发起连接请求，但因网络延时因素，客户端关闭了连接，而延时一段时间后，请求到达了web服务器，如果是两次握手，那么服务端就没有额外的机会获知客户端此时是否还需要建立连接。 四次挥手是因为请求释放连接时，web服务器可能还处于报文发送中状态，三次沟通不能解决该问题

有新想法再更新。。。