紧接着上文Dubbo分析之Transport层，本文继续介绍Exchange层，此层官方介绍为信息交换层：封装请求响应模式，同步转异步，以 Request, Response 为中心，扩展接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer；下面分别进行介绍

上一篇文章Dubbo分析之Serialize层，介绍了最底层的序列化/反序列化层，本文继续分析Serialize层的上一层transport网络传输层，此层使用了现有的一些通讯开源框架(ex:netty,mina,grizzly)来做底层通讯，上文也做了简单介绍，本文将做更深入的了解；

最近在使用一个内部的RPC框架时，发现如果使用Object类型，实际类型为BigDecimal的时候，作为传输对象的时候，会出现丢失精度的问题；比如在序列化前为金额1.00，反序列化之后为1.0，本身值可能没有影响，但是在有些强依赖金额的地方，会出现问题；

图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口；图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系；图中绿色小块的为扩展接口，蓝色小块为实现类，图中只显示用于关联各层的实现类；图中蓝色虚线为初始化过程，即...

前几篇文章分别从使用和源码层面对Quartz做了简单的分析，在分析的过程中也发现了Quartz不足的地方；比如底层调度依赖数据库的悲观锁，谁先抢到谁调度，这样会导致节点负载不均衡；还有调度和执行耦合在一起，导致调度器会受到业务的影响；下面看看如何来解决这几个问题；

消息是自包含的自主性实体，在设计分布式消息应用程序时，要将此作为头条法则；当JMS客户端发送一条消息时，它就完成了它的所有工作，一旦该数据被传送出去，它就被认为是”安全的”，而且不在受该客户端的控制，类似JDBC客户端和数据库直接的约定；

上文中简单的介绍了Spring-Cloud-Config如何使用，如何手动更新配置文件，并且在文末提出了几个疑问，其中包括多个Client节点如何更新，Server端如何保证高可用性等；本文将重点介绍通过使用Spring Cloud Bus来批量更新客户端，以及Server如何保证高可用；

Spring-Cloud-Config是Sping-Cloud下用于分布式配置管理的组件，分成了两个角色Config-Server和Config-Client；Config-Server端集中式存储/管理配置文件，并对外提供接口方便Config-Client访问，接口使用HTTP的方式对外提供访问；Config-Client通过接口获取配置文件，然后可以在应用中使用；Config-Server存储/管理的配...

在上文Tomcat Session管理分析介绍了使用tomcat-redis-session-manager来集中式管理session，其中一个局限性就是必须使用tomcat容器；本文介绍的spring-session也能实现session的集中式管理，并且不局限于某种容器；

在上文Nginx+Tomcat关于Session的管理中简单介绍了如何使用redis来集中管理session，本文首先将介绍默认的管理器是如何管理Session的生命周期的，然后在此基础上对Redis集中式管理Session进行分析。

Nginx+Tomcat对Session的管理一直有了解，但是一直没有实际操作一遍，本文从最简单的安装启动开始，通过实例的方式循序渐进的介绍了几种管理session的方式。

数据库锁定机制简单来说就是数据库为了保证数据的一致性而使各种共享资源在被并发访问访问变得有序所设计的一种规则；对于任何一种数据库来说都需要有相应的锁定机制，Mysql也不例外。

https：一种安全的http协议，因此可以称为安全的超文本传输协议，https提出在http和tcp之间添加一层加密层(SSL层)，这一层负责数据的加密和解密。数字证书：简称CA，它由权威机构给某网站颁发的一种认可凭证，是被浏览器所认可的，当然证书也可以自己生成，但是这样就不被浏览器所认可，想想如果自己随便生成一个证书就...

Quartz内部提供的调度类是QuartzScheduler，而QuartzScheduler会委托QuartzSchedulerThread去实时调度；当调度完需要去执行job的时候QuartzSchedulerThread并没有直接去执行job，而是交给ThreadPool去执行job，具体使用什么ThreadPool，初始化多线线程，可以在配置文件中进行配置：

上一篇文章Spring整合Quartz分布式调度介绍了Quartz通过数据库的方式来实现分布式调度，通过使用数据库来存储trigger，job等信息，可以在停服重启的时候重新加载上次trigger的状态，保证了完整性；另一方面通过数据库来实现锁机制来实现分布式调度；Quartz默认提供了11张表，本文将对这几张表做简要的分析。

为了保证应用的高可用和高并发性，一般都会部署多个节点；对于定时任务，如果每个节点都执行自己的定时任务，一方面耗费了系统资源，另一方面有些任务多次执行，可能引发应用逻辑问题，所以需要一个分布式的调度系统，来协调每个节点执行定时任务。

问题描述最近通知应用在近三个月内出现过2次DNS缓存的问题，第一次在重启之后一直没有出现过问题，所以也没有去重视，但是最近又出现过一次，看来很有必要彻底排查一次；具体的错误日志如下：

前言最近一段时间一直再看mysql binlog相关的内容，也整理了几篇相关的文章，对mysql的事件以及通讯协议在理论上有了一个大概的了解，但是缺少实战；本文的目的就是从实战出发，了解binlog解析的整个过程。

Zipkin是什么Zipkin分布式跟踪系统；它可以帮助收集时间数据，解决在microservice架构下的延迟问题；它管理这些数据的收集和查找；Zipkin的设计是基于谷歌的Google Dapper论文。每个应用程序向Zipkin报告定时数据，Zipkin UI呈现了一个依赖图表来展示多少跟踪请求经过了每个应用程序；如果想解决延迟问题，可以过滤或者...

前言上一篇文件MySql Binlog初识，对Binlog的参数，格式以及个别事件做了详细介绍，但是Binlog事件数量比较多，上篇文章中没有对所有事件进行介绍；本文将对Binlog的事件进行简单说明，必要的时候通过SQL触发相关的事件，以下基于Mysql5.5，5.0以前的版本不考虑。

Mysql日志MySQL 的日志包括错误日志（ErrorLog），更新日志（Update Log），二进制日志（Binlog），查询日志（Query Log），慢查询日志（Slow Query Log）等；更新日志是老版本的MySQL 才有的，目前已经被二进制日志替代；在默认情况下，系统仅仅打开错误日志，关闭了其他所有日志，以达到尽可能减少IO损耗提高系统，性...