知识积累

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

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服务器可能还处于报文发送中状态，三次沟通不能解决该问题

有新想法再更新。。。