Homebrew简介

引用 官方 的一句话：Homebrew是Mac OS 不可或缺的套件管理器。

Homebrew是一款Mac OS平台下的软件包管理工具，拥有安装、卸载、更新、查看、搜索等很多实用的功能。简单的一条指令，就可以实现包管理，而不用你关心各种依赖和文件路径的情况，十分方便快捷。

所以它是Mac必备神器Homebrew。

安装时遇到的错误一

安装的命令很简单如下

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

当你在国内运行上面命令时会遇到下面的错误

curl: (7) Failed to connect to raw.githubusercontent.com port 443: Connection refused

这是因为被墙了，如果你是科学上网的话，就使用你上网的神器来代理，这块我想说的就是使用代理收费的肯定比免费的要好一些，如果可以的话花钱买一个，毕竟天天都要使用。

那么如何代理？使用下面命令

假设我的代理http端口是：1087，socket是：869

export https_proxy=http://127.0.0.1:1087 http_proxy=http://127.0.0.1:1087 all_proxy=socks5://127.0.0.1:869

ps. 将端口替换成你自己的代理端口，输入上面的命令代理只会在本次打开的terminal生效。

设置完代理之后再运行安装命令就不会看到无法连接raw.githubusercontent.com，紧接着提示需要你输入电脑密码，输入密码后它会提示你如下信息：

==> This script will install:
/usr/local/bin/brew
/usr/local/share/doc/homebrew
/usr/local/share/man/man1/brew.1
/usr/local/share/zsh/site-functions/_brew
/usr/local/etc/bash_completion.d/brew
/usr/local/Homebrew

Press RETURN to continue or any other key to abort

输入回车直接安装即可。

安装时遇到的错误二

这里需要注意一个问题，它会去github上下载Homebrew代码进行安装。代码现在完后安装他会卡在某一个地方，比如说我这里卡在

==> /usr/bin/sudo /usr/sbin/chown jiuye:admin /usr/local/Homebrew
==> Downloading and installing Homebrew...
HEAD is now at 48e44870e Merge pull request #10334 from SeekingMeaning/rubocop-spec-descriptions

长时间卡在这里不动，我直接Control + C退出，因为源码已经下载安装完成，其余的不知道为啥卡在这里，但是它已经安装成功了。

退出后运行brew -v测试一下是否可用，如果可以使用就证明安装成功。

使用brew安装工具包遇到的错误三

比如说我们安装wget的时候会遇到如下问题，它会长时间卡如下地方

Updating Homebrew...

如果长时间卡在升级homebrew的话，我们可以尝试Control + C退出homebrew升级，这个时候它会跳过升级直接安装我们需要的包直到安装结束，如下所示：

MacBook-Pro:~ jiuye$ brew install wget
==> Downloading https://homebrew.bintray.com/bottles-portable-ruby/portable-ruby-2.6.3_2.yosemite.bottle.tar.gz
######################################################################## 100.0%
==> Pouring portable-ruby-2.6.3_2.yosemite.bottle.tar.gz
Updating Homebrew...

^C==> Downloading https://homebrew.bintray.com/bottles/gettext-0.20.2_1.mojave.bot
==> Downloading from https://d29vzk4ow07wi7.cloudfront.net/52067198cab528f05fdc0
######################################################################## 100.0%
==> Downloading https://homebrew.bintray.com/bottles/libunistring-0.9.10.mojave.
==> Downloading from https://d29vzk4ow07wi7.cloudfront.net/1d0c8e266acddcebeef3d
######################################################################## 100.0%

到目前为止我们就成功的安装和测试了Homebrew，本次主要收录我在使用过程中遇到的问题，如果后续安装其他包遇到其他问题的话，我也会持续的更新它收录在一起。

特殊说明

到最后要说明一点，Homebrew在安装软件包的时候，它会将软件包安装到独立目录，并将其文件软链接至 /usr/local ，通过ls -l查看

ls -l /usr/local/bin/

lrwxr-xr-x  1 xxx  xxx        32  1 18 13:33 wget -> ../Cellar/wget/1.20.3_2/bin/wget
-rwxr-xr-x  1 xxx  xxx       123  3  7  2019 wish
-rwxr-xr-x  1 xxx  xxx       123  3  7  2019 wish8.6
lrwxr-xr-x  1 xxx  xxx        39  1 18 13:33 xgettext -> ../Cellar/gettext/0.20.2_1/bin/xgettext

为了数据安全我们在开发过程中经常会对重要的数据进行加密存储，常见的有：密码、手机号、电话号码、详细地址、银行卡号、信用卡验证码等信息，这些信息对加解密的要求也不一样，比如说密码我们需要加密存储，一般使用的都是不可逆的慢hash算法，慢hash算法可以避免暴力破解（典型的用时间换安全性），在检索时我们既不需要解密也不需要模糊查找，直接使用密文完全匹配，但是手机号就不能这样做，因为手机号我们要查看原信息，并且对手机号还需要支持模糊查找，因此我们今天就针对可逆加解密的数据支持模糊查询来看看有哪些实现方式。

在网上随便搜索了一下，关于《加密后的模糊查询》 的帖子很多，顺便整理了一下实现的方法，不得不说很多都是不靠谱的做法，甚至有一些沙雕做法，接下来我们就对这些做法来讲讲实现思路和优劣性。

如何对加密后的数据进行模糊查询

我整理了一下对加密的数据模糊查询大致分为三类做法，如下所示：

• 沙雕做法（不动脑思考直男的思路，只管实现功能从不深入思考问题）
• 常规做法（思考了查询性能问题，也会使用一些存储空间换性能等做法）
• 超神做法（比较高端的做法从算法层面上思考）

我们就对这三种实现方法一一来讲讲实现思路和优劣性，首先我们先看沙雕做法。

沙雕做法

• 将所有数据加载到内存中进行解密，解密后通过程序算法来模糊匹配
• 将密文数据映射一份明文映射表，俗称tag表，然后模糊查询tag来关联密文数据

沙雕一

我们先来看看第一个做法，将所有数据加载到内存中进行解密，这个如果数据量小的话可以使用这个方式来做，这样做既简单又实惠，如果数据量大的话那就是灾难，我们来大致算一下。

一个英文字母(不分大小写)占一个字节的空间，一个中文汉字占两个字节的空间，用DES来举例，13800138000加密后的串HE9T75xNx6c5yLmS5l4r6Q==占24个字节。

轻则上百兆，重则上千兆，这样分分钟给应用程序整成Out of memory，这样做如果数据少只有几百、几千、几万条时是完全可以这样做的，但是数据量大就强烈不建议了。

沙雕二

我们再来看第二个做法，将密文数据映射一份明文映射表，然后模糊查询映射表来关联密文数据，what？？？！！！那我们为什么要对数据加密呢，直接不加密不是更好么！

我们既然对数据加密肯定是有安全诉求才会这样做，增加一个明文的映射表就违背了安全诉求，这样做既不安全也不方便完全是脱裤子放x，多此一举，强且不推荐。

常规做法

我们接下来看看常规的做法，也是最广泛使用的方法，此类方法及满足的数据安全性，又对查询友好。

• 在数据库实现加密算法函数，在模糊查询的时候使用decode(key) like '%partial%
• 对密文数据进行分词组合，将分词组合的结果集分别进行加密，然后存储到扩展列，查询时通过key like '%partial%'

常规一

在数据库中实现与程序一致的加解密算法，修改模糊查询条件，使用数据库加解密函数先解密再模糊查找，这样做的优点是实现成本低，开发使用成本低，只需要将以往的模糊查找稍微修改一下就可以实现，但是缺点也很明显，这样做无法利用数据库的索引来优化查询，甚至有一些数据库可能无法保证与程序实现一致的加解密算法，但是对于常规的加解密算法都可以保证与应用程序一致。

如果对查询性能要求不是特别高、对数据安全性要求一般，可以使用常见的加解密算法比如说AES、DES之类的也是一个不错的选择。

如果公司有自己的算法实现，并且没有提供多端的算法实现，要么找个算法好的人去研究吃透补全多端实现，要么放弃使用这个办法。

常规二

对密文数据进行分词组合，将分词组合的结果集分别进行加密，然后存储到扩展列，查询时通过key like '%partial%'，这是一个比较划算的实现方法，我们先来分析一下它的实现思路。

先对字符进行固定长度的分组，将一个字段拆分为多个，比如说根据4位英文字符（半角），2个中文字符（全角）为一个检索条件，举个例子：

ningyu1使用4个字符为一组的加密方式，第一组ning ，第二组ingy ，第三组ngyu ，第四组gyu1 … 依次类推。

如果需要检索所有包含检索条件4个字符的数据比如：ingy ，加密字符后通过 key like “%partial%” 查库。

我们都知道加密后长度会增长，增长的这部分长度存储就是我们要花费的额外成本，典型的使用成本来换取速度，密文增长的幅度随着算法不同而不同以DES举例，13800138000加密前占11个字节，加密后的串HE9T75xNx6c5yLmS5l4r6Q==占24个字节，增长是2.18倍，所以一个优秀的算法是多么的重要，能为公司节省不少成本，但是话又说回来算法工程师的工资也不低，所以我也不知道是节省成本还是增加成本，哈哈哈…你们自己算吧。

回到主题，这个方法虽然可以实现加密数据的模糊查询，但是对模糊查询的字符长度是有要求的，以我上面举的例子模糊查询字符原文长度必须大于等于4个英文/数字，或者2个汉字，再短的长度不建议支持，因为分词组合会增多从而导致存储的成本增加，反而安全性降低。

大家是否都对接过 淘宝、拼多多、JD他们的api，他们对平台订单数据中的用户敏感数据就是加密的同时支持模糊查询，使用就是这个方法，下面我整理了几家电商平台的密文字段检索方案的说明，感兴趣的可以查看下面链接。

淘宝密文字段检索方案
阿里巴巴文字段检索方案
拼多多密文字段检索方案
京东密文字段检索方案

ps. 基本上都是一样的，果然都是互相抄袭，连加密后的数据格式都一致。

这个方法优点就是实现起来不算复杂，使用起来也较为简单，算是一个折中的做法，因为会有扩展字段存储成本会有升高，但是可利用数据库索引优化查询速度，推荐使用这个方法。

超神做法

我们接下来看看优秀的做法，此类做法难度较高，都是从算法层面来考虑，有些甚至会设计一个新算法，虽然已有一些现成的算法参考，但是大多都是半成品无法拿来直接使用，所以还是要有人去深入研究和整合到自己的应用中去。

• 从算法层面思考，甚至会设计一个新算法来支持模糊查找

这个层面大多是专业算法工程师的研究领域，想要设计一个有序的、非不可逆的、密文长度不能增长过快的算法不是一件简单的事情，大致的思路是这样的，使用译码的方式进行加解密，保留密文和原文一样的顺序，从而支持密文模糊匹配，说的比较笼统因为我也不是这方面的专家没有更深一步的研究过，所以我从网上找了一些资料可以参考一下。

• 数据库中字符数据的模糊匹配加密方法

这里提到的Hill密码处理和模糊匹配加密方法FMES可以重点看看.

• 一种基于BloomFilter的改进型加密文本模糊搜索机制研究

• 支持快速查询的数据库如何加密

• 基于Lucene的云端搜索与密文基础上的模糊查询

基于Lucene的思路就跟我们上面介绍的常规做法二类似，对字符进行等长度分词，将分词后的结果集加密后存储，只不过存储的db不一样，一个是关系型数据库，一个是es搜索引擎。

• 云存储中一种支持可验证的模糊查询加密方案

总结

我们到这里对加密数据的检索方案全部介绍完了，我们首先提到的是网上搜索随处可见的沙雕做法，在这里也讲了不推荐使用这些沙雕做法，尽量使用常规做法，如果公司有专业算法方向人才的话不妨可以考虑基于算法层面的超神做法。

总的来说从投入、产出比、及实现、使用成本来算的话常规做法二是非常推荐的。

最后送上那句老话，Keep Real，Love and peace！

我相信大部分人都看到过这样的新闻，某某论坛泄漏了用户密码，某某物流公司泄漏了用户的手机号等等，我一直坚信大部分数据泄漏都是内部管理出现了问题，大部分都是内部团队有意或无意泄漏了数据，如果要从外界通过漏洞攻克不是没有可能但是成本是巨大的，所以人为的泄漏往往是需要更加关注的问题，那作为软件生产的主力军（程序员）如何来避免挖坑？那我们接下来就主要讲讲从开发角度如何避免数据泄漏的可能性。

从网上找了一些 数据安全治理 的相关资料，有兴趣可以参考一下。

我们从程序员角度来讲讲如何有效的预防数据安全问题。

数据的访问控制

我们先来看看哪些是经常访问数据库的用户？

1. 软件程序（应用程序、数据库中间件）
2. 人员：运维、开发、测试、产品、等

那接下来我们就来看看从这几点如何来控制数据库的访问。

软件程序层面

这里说的软件程序包含：应用程序、数据库中间件等，作为数据库的第一用户我们如何有效的规避数据安全的问题呢？

我们先来说说现在的软件开发用到的一些框架，无论是java、go、python或其他，已经有很丰富的orm和datasource框架或工具，我下面罗列一些java中常用jdbc连接池和orm框架以及数据库中间件

我相信很多程序的数据库连接与密码都是通过配置文件来保存的，假如应用服务器被黑客利用软件漏洞拿下，我相信通过部署的软件可以翻出数据库连接的配置，那么针对这一点我们如何有效的避免呢？

数据库连接密码加密

一般我们为了做数据库高可用都会给数据库集群中间做一层代理，通过域名的方式来暴漏连接，这样做的好处就是数据库failover的时候应用程序可以不需要重启，只用重新创建连接即可。因此这层代理可以有效的防止数据库真实部署的机器被暴漏出去，起到了一定的安全作用。

虽然连接层面有一层代理来杜绝真实服务器被暴漏，但是我们在通过jdbc连接的时候往往是有密码访问的，我相信很多数据库的密码是明文的存储在配置文件中，虽然现在都用配置中心（configcenter）来统一管理应用的配置，如果使用明文来保存密码始终是无法规避泄漏的风险，因为应用程序始终要进行连接，在连接的时候要读取配置，不管配置是从云端同步下来还是从本地读取，只要是明文存储密码的就会存在安全问题。

其实大多的数据库连接池都有对数据库访问密码加解密的功能，因此我们可以通过把数据库访问的密码进行加密来解决安全问题。

下来我使用druid举个例子，具体的看看如何使用，也可以查看druid官方 示例

通过使用ConfigFilter为数据库密码提供加密功能

<bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource"
        destroy-method="close">
    .................
    <!-- 如果fitlers走的配置中心，请去配置中心修改 -->
    <property name="filters" value="${filters}" />
    <!-- 如果没有配置中心请直接修改 -->
    <property name="filters" value="stat,config" /> 
    <!-- 以上两种filters配置2选一 -->
     
    <property name="connectionProperties" value="config.decrypt=true;config.decrypt.key=${publickey}" />
    .................
</bean>

filters=stat
改为
filters=stat,config
 
jdbc.xxxx.password=123456
改为
jdbc.xxxx.password=加密后的值
 
增加
publickey=公钥

ps. 如果使用的是配置中心那么创建对应的配置项即可。

非对称秘钥对的生成方式有很多种，这里我给个在线生成的链接 加密后的密文是一段比较长的字符，例如下面这段示例

jdbc.password=p9i+fChqlaYnfhI+NoJqmrGwTyWwlFZ1W7Vi7i2MGZ8agFkGxGr/kWU//yDvPyXZ6YwJwnMKQ4zXpTZnfxWaRjfqWIRG+JzxSdSYEMp/bRCiIvzF6y8FdVCqN/0m0eQeZFvMCdIf4wqhKF0QRCEOTysZ3oGg7t5o35CIMpV1A5Y=

其他的jdbc连接池也都有类似的功能，但是不排除有一些没有这个功能的就需要我们自己动手开发来增强这部分功能。

首先我们需要了解数据库连接加解密的思路，只要有思路实现都是很简单的，其实数据库连接加解密思路很简单，在真正创建数据库连接的时候读取加密的密码进行解密后再进行数据库连接，那接下来我们给dbcp扩展这个功能。

import java.sql.SQLFeatureNotSupportedException;
import java.util.Properties;
import java.util.logging.Logger;

import org.apache.commons.dbcp.BasicDataSource;
import org.slf4j.LoggerFactory;

public class SecurityBasicDataSource extends BasicDataSource {

private final org.slf4j.Logger logger = LoggerFactory.getLogger(SecurityBasicDataSource.class);

@Override
public Logger getParentLogger() throws SQLFeatureNotSupportedException {
throw new SQLFeatureNotSupportedException();
}

@Override
public void setPassword(String password) {
try {
//这里可以从任意地方读取数据库配置
Properties p = ConfigLoaderUtils.loadConfig("jdbc.properties");
String publickey = p.getProperty("publickey");
//ConfigTools是实现私钥、公钥对加解密实现
password = ConfigTools.decrypt(publickey, password);
super.setPassword(password);
} catch(Exception e) {
logger.error("解密password出错", e);
}
}

}

• 首先我们继承dbcp数据源org.apache.commons.dbcp.BasicDataSource
• 重写setPassword
• 设置密码的时候通过公钥和密文进行解密

这样我们就给dbcp扩展了数据库连接加解密的功能，是不是很简单。

到这里我们就对数据库连接密码加密的方法介绍完毕，这样做的好处有什么呢？假设当应用服务器被坏人俘虏后，他想通过应用的配置信息轻松的获取数据库访问密码是不太可能，采用 公开密钥加密 安全性还是很高的，它是一种非对称加密算法想要了解更多的可以点开维基百科的连接查看。

敏感数据加解密

前面我们介绍完了数据库连接上的安全问题以及如何解决，接下来我们继续介绍数据库中存储的敏感数据应该如何处理。

我相信很多人都接触过导出生产数据需要经过 数据脱敏 ，需要经过数据脱敏的大多都是存储的明文数据，比如说用户的手机号、详细地址、银行卡号、信用卡验证码、用户密码、等。

如果我们将这些敏感数据在存储入库的时候进行加密，数据库中存储的是密文数据，这样及时被脱库我相信也没有那么容易破解，有人可能说密码破解外界有 彩虹表 ，彩虹表是一个用于加密散列函数逆运算的预先计算好的表，常用于破解加密过的密码散列，针对于用户详细地址、银行卡号我相信彩虹表是无能为力的，如果使用暴力破解时间上的成本也是难以想象的，可能需要xxxxxx亿年，哈哈哈。

我们对数据加解密使用对称加解密算法AES或DES，为什么不使用非对称的公开密钥加密 ？

虽然非对称加解密算法安全性高，但是非对称加解密算法加密后的值太长不利于存储，所以我们需要使用固定长度或者可控长度的加解密算法，刚好对称加解密算法符合要求，这里使用DES作为示例，当然可以替换成任意的加解密算法。

先说说数据落库时的加解密实现思路，假设我们需要存储用户详情，其中有姓名、电话、联系地址、银行卡号等信息，我们在持久化用户详情的时候对敏感字段进行加密计算出密文，再将密文存入数据库，当查询用户详情的时候，先从数据库查询出密文，通过对密文的解密和脱敏再返回给前台，这样我们就可以达到我们想要的效果，这里需要特殊说明一下，密文对模糊查询不是很友好，但是也可以实现模糊查询，具体的实现思路有很多种，这里我们就不多做介绍，感兴趣的话我后面可以单独出一篇支持模糊查询的加解密算法，回到主题我们就以这个案例进行实现。

首先我们需要对敏感字段进行打标记，java的annotation可以帮助我们实现打标

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface Cipher {
}

我们可以给用户对象的敏感字段：手机号、银行卡、详细地址 上标注@Cipher注释，说明这几个字段我们在保存、修改的时候需要加密，在查询的时候需要解密。

下来我们就要找一个公共的地方来统一的进行加解密处理，作为一名合格的程序员需要想尽一切办法来偷懒，并不是在所有CRUD的地方进行加解密调用这样会很傻很天真，作为被广泛使用的orm框架之一的mybatis这里我使用它作为示例讲解实现思路。

mybatis提供拦截器机制，可以对执行的CRUD进行拦截处理操作，pagehelper 是一个分页的mybatis插件，就是利用拦截的机制来扩展分页功能。

我们刚才有说过我们需要对insert、update操作进行加密，对select操作进行解密，在mybatis的底层保存和修改都是update方法，查询都是query方法，刚好我们就对这两个方法进行拦截处理。

import java.lang.reflect.Field;
import java.util.List;
import java.util.Properties;

import org.apache.commons.lang3.StringUtils;
import org.apache.ibatis.executor.Executor;
import org.apache.ibatis.mapping.MappedStatement;
import org.apache.ibatis.plugin.Interceptor;
import org.apache.ibatis.plugin.Intercepts;
import org.apache.ibatis.plugin.Invocation;
import org.apache.ibatis.plugin.Plugin;
import org.apache.ibatis.plugin.Signature;
import org.apache.ibatis.session.ResultHandler;
import org.apache.ibatis.session.RowBounds;
import org.apache.ibatis.session.defaults.DefaultSqlSession.StrictMap;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

@Intercepts({
        @Signature(type = Executor.class, method = "update", args = { MappedStatement.class, Object.class }),
        @Signature(type = Executor.class, method = "query", args = { MappedStatement.class, Object.class,
                RowBounds.class, ResultHandler.class }) })
public class CipherHelper implements Interceptor {
    
    private final Logger logger = LoggerFactory.getLogger(CipherHelper.class);

    /**
     * 加密密钥</br> 为null，使用默认密钥进行加解密</br>
     */
    private String secureKey = null;
    /**
     * 是否允许宽容处理</br> 宽容处理的话，使用原值，反之throw {@link CipherException}</br>
     */
    private boolean lenient = false;

    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        String methodName = invocation.getMethod().getName();
        if (methodName.equals("update") || methodName.equals("query")) {
             Object parameter = invocation.getArgs()[1];
            if (parameter instanceof List) {
                List<?> list = (List<?>) parameter;
                for (Object obj : list) {
                    encrypt(obj);
                }
            } else if(parameter instanceof StrictMap) {
                StrictMap<?> strictMap = (StrictMap<?>) parameter;
                if (strictMap.containsKey("list")) {
                    List<?> list = (List<?>) strictMap.get("list");
                    for (Object obj : list) {
                        encrypt(obj);
                    }
                } else if (strictMap.containsKey("array")) {
                    Object[] objects = (Object[]) strictMap.get("array");
                    for (Object obj : objects) {
                        encrypt(obj);
                    }
                }
            } else {
                encrypt(parameter);
            }
        }
        Object returnValue = invocation.proceed();
        if (methodName.equals("query")) {
            if (returnValue instanceof List) {
                List<?> list = (List<?>) returnValue;
                for (Object obj : list) {
                    decrypt(obj);
                }
            } else {
                decrypt(returnValue);
            }
        }
        return returnValue;
    }

    /**
     * 加密处理
     * 
     * @param parameter
     * @throws IllegalAccessException
     */
    private void encrypt(Object parameter) throws IllegalAccessException {
        if (parameter == null) return;
        Class<?> clazz = parameter.getClass();
        if (!clazz.getSimpleName().endsWith("Entity")) {
            return;
        }
        for (; clazz != Object.class; clazz = clazz.getSuperclass()) {
            Field[] fields = clazz.getDeclaredFields();
            for (int i = 0; i < fields.length; i++) {
                if (!fields[i].isAnnotationPresent(Cipher.class)) {
                    continue;
                }
                if (!fields[i].getType().equals(String.class)) {
                    logger.debug("加密字段只支持String类型,当前类型非String,跳过!");
                    continue;
                }
                fields[i].setAccessible(true);
                String v = (String) fields[i].get(parameter);
                if (StringUtils.isBlank(v)) {
                    logger.debug("加密字段值为null,跳过!");
                    continue;
                }
                try {
                    String crypt = DESTools.encrypt(secureKey, v);
                    fields[i].set(parameter, crypt);
                    logger.debug("加密处理字段,{}", fields[i].getName());
                } catch (Exception e) {
                    if (lenient) {
                        logger.warn("加密处理失败,宽容处理使用原值");
                    } else {
                        throw new CipherException("加密处理失败,不允许宽容处理["+v+"]", e);
                    }
                }
            }
        }
    }

    /**
     * 解密处理
     * 
     * @param obj
     * @throws IllegalAccessException
     * @throws Exception
     */
    private void decrypt(Object obj) throws IllegalAccessException, Exception {
        if (obj == null) return;
        Class<?> clazz = obj.getClass();
        if (!clazz.getSimpleName().endsWith("Entity")) {
            return;
        }
        for (; clazz != Object.class; clazz = clazz.getSuperclass()) {
            Field[] fields = clazz.getDeclaredFields();
            for (int i = 0; i < fields.length; i++) {
                if (!fields[i].isAnnotationPresent(Cipher.class)) {
                    continue;
                }
                if (!fields[i].getType().equals(String.class)) {
                    logger.debug("解密字段只支持String类型,当前类型非String,跳过!");
                    continue;
                }
                fields[i].setAccessible(true);
                String v = (String) fields[i].get(obj);
                if (StringUtils.isBlank(v)) {
                    logger.debug("解密字段值为null,跳过!");
                    continue;
                }
                try {
                    String crypt = DESTools.decrypt(secureKey, v);
                    fields[i].set(obj, crypt);
                    logger.info("解密处理字段,{}", fields[i].getName());
                } catch (Exception e) {
                    if (lenient) {
                        logger.warn("解密处理失败,宽容处理使用原值");
                    } else {
                        throw new CipherException("解密处理失败,不允许宽容处理["+v+"]", e);
                    }
                }
            }
        }

    }

    @Override
    public Object plugin(Object target) {
        return Plugin.wrap(target, this);
    }

    @Override
    public void setProperties(Properties properties) {
        if (properties != null && StringUtils.isNotBlank(properties.getProperty("secureKey"))) {
            this.secureKey = properties.getProperty("secureKey");
        }
        if (properties != null && StringUtils.isNoneBlank(properties.getProperty("lenient"))) {
            this.lenient = Boolean.parseBoolean(properties.getProperty("lenient"));
        }

    }

}

通过mybatis的插件扩展机制在执行过程进行拦截处理，plugin方法是插件的装载方法，setProperties方法设置关键属性，比如说密钥串。

接下来我们对每个方法进行讲解：

encrypt：是加密方法，这里加密方法需要注意的是，mybatis参数支持Pojo 、Map、StrictMap、List、Array，我们使用注解@Cipher是用在类上的所以只对Pojo生效，如果是Map它天生的key，value格式无法支持打标，我们这里对Map类型进行跳过不处理，如果非要处理Map也是有办法的，需要固定加解密的key值，对特定的key进行识别并加解密替换value，加密方法通过查找有注解@Cipher的字段进行加密并且回填值。

decrypt：是解密方法，主要用在查询时的解密，这里需要注意的是查询有可能返回特定的Pojo也可能返回List，所以这里解密的时候需要根据类型来分别处理，如果是List需要进行很层次查找，如果是Pojo那就查找使用注解@Cipher的字段进行解密并且回填值。

intercept：是拦截方法，在update、query前后进行拦截处理，在这个方法里需要进行如下步骤：

• 识别当前执行的method是update还是query
  • 如果是update那就进行加密
  • 如果是query那就进行解密
• 识别参数类型是List、StrictMap、Pojo
  • 如果是List需要再深层次看一下List里是什么类型，这里建议使用递归方式
    • 如果List里是Pojo那就循环调用encrypt方法
    • 如果List里是Map跳过处理，或者使用上面我们说的识别某些固定key进行加密处理
  • 如果是StrictMap需要再深层次看一下StrictMap里是什么类型，这里建议使用递归方式
    • 如果StrictMap里是list那就循环调用encrypt方法
    • 如果StrictMap里是array那就循环调用encrypt方法
  • 如果是Pojo那就调用encrypt方法
• 执行sql处理获取返回值
• 获取返回值并且执行的方法是query时，进行解密处理
  • 识别返回的类型是List还是Pojo
    • 如果是List深层次查找内部类型，这里建议使用递归方式
      • 如果List里是Pojo那就循环调用decrypt方法
      • 如果List里是Map跳过处理，或者使用上面我们说的识别某些固定key进行解密处理
    • 如果是Pojo那就调用decrypt方法

到这里数据加解密的核心逻辑就介绍完了。

这里我们回顾一下，我们先是对数据库连接密码进行加解密，然后又对敏感数据落库和查询时进行加解密，第一步连接密码加密预防坏人即使攻击拿到了应用服务器的操作权限他也无法轻易的攻克我们的数据库访问密码，第二步敏感数据加解密预防坏人即使攻克了我们的数据库（俗称脱库）他也无法获取用户的隐私数据，这样就有效的保证了用户隐私数据的安全性。

到这里我们就对软件程序层面的数据安全防护手段介绍完毕，接下来我们再从人员访问控制方面来看看有什么有效的手段。

人员层面

前面我们说了绝大多数的数据泄密都不是技术问题而是人员管理问题，我们要对人员进行有效的管理与控制。

开发或测试人员

这类人一般对数据是有CRUD的诉求，针对这类人员的控制有如下几个方面

• 开发人员只能连接测试环境数据库，不允许连接生产数据库，即使连接vpn也不行。
• 开发人员申请数据库需要走运维工单流程，运维提供数据库连接密码时应直接提供密文，或者运维直接给配置到配置中心。
• 配置文件或配置中心禁止存储明文密码，需要对jdbc等其他敏感密码进行脱敏处理。
• 生产服务器需要通过跳板机访问，禁止开发使用root直接操作，如果看应用日志可以走日志平台，实在没有日志平台可以给跳板机开通app用户只给查看固定目录日志的权限，如果要发布走devops平台，如果没有可以提供给运维进行发布。
• 查询生产数据走dms平台，对敏感信息进行脱敏或隐藏，对上线的sql和日常的查询日志做到dms可管控。
• 提交到开放环境时需要注意以下几点
  • 提交到开放的仓库（github、gitlab、gitee等），需要对代码进行审核，避免有hardcode的公司服务器密码、ip、端口、密钥等。
  • 提交到开放的论坛（csdn、oschina、知乎、公众号、社区分享等），需要对文章进行审核，避免有不允许公开的技术细节或敏感信息。

运维或DBA人员

这类人一般操作权限都很高，出问题概率最高的人员，有很多删库跑路或误操作rm -rf的例子哈哈哈！所以这类人更要重点管控。

• 需要搭建和处理运维工单平台，用于开发提出的运维资源申请，尤其是数据库密码，直接提供加密后的密文和公钥。
• 需要搭建和处理数据库管理工具dms，用于开发日常生产数据查询和发版时SQL升级。
• 需要提供跳板机和给跳板机提供不同等级的用户，提供给特别需要的人访问生产环境机器。
• 需要提供devops平台或者自动化发版工具，避免手动操作失误带来问题，对开发提供升级发布的流水线。
• 对服务器密码需要进行加密存储，可以借助密码管理工具。
• 运维最好也不要使用root用户操作服务器，使用特定权限的用户操作。
• dba最好也不要使用root用户操作数据库，使用特定权限的用户操作。
• 制定责任人机制，对应的责任项必须到具体人，具体可以参考 责任分配矩阵RAM 。
• 关键重要的操作需要至少两个人在场，具体可以参考 责任分配矩阵RAM 。

产品或业务人员

这类人一般对数据有查询和分析的诉求，有分析诉求就需要导出数据，所以分析诉求统一走公司BI工具，也有少部分有修改的诉求。

• 查询分析数据，统一接入BI工具，并且BI工具需要有功能和数据权限，并对敏感数据导出加以控制，导出走审批并脱敏。
• 提交数据变更，统一接入dms平台。
• 产品的分析文件（word、excel、ppt）应该进行加密，这种一般依赖公司引入文档安全的解决方案，要花钱的，如果不想花钱那就没啥好办法。

总结

到这里整篇也就差不多都介绍完了，我们现在回顾一下，首先我们介绍了数据安全的问题，并且说明了安全问题一般发生在两个方面，一个是软件程序，一个是人员管理。

我们在软件程序方面介绍了两种预防数据安全的手段，一个是数据库连接密码加解密，一个是数据加解密，数据库连接加密可以有效预防服务器被攻击后通过翻找程序来进一步攻击数据库，数据加解密可以有效预防数据库被攻击或脱库后泄漏用户及公司隐私数据。

我们在人员方面首先对人员进行了分类，针对每一类人的诉求谈了管控的手段，说了这么多的控制手段，并不是说对员工不信任，我们这里说的控制并不等于限制，说了这么多的终极目标是搭建一套有序的安全的管理机制，在安全的范围内给员工提供最大化的发挥空间，规避有心或无心的泄密，最后送上那句老话，Keep Real，Love and peace！

什么是CI？ 持续集成，Continuous Integration，简称 CI

什么是CD？ 持续交付，Continuous Deployment，简称CD

我们都知道软件开发写代码只是其中的一部分，写出代码后需要构建（build）、测试（test）、发布（deploy）。

这些都是比较按部就班的操作，所以有很多工具化的支持，为了提高软件开发效率，构建和测试的工具有很多，我们最熟知的是jenkins，相信很多人都用过，还有很多如gitlab-ci、travis-ci、等。

今天我们就说一下travis-ci的简单使用，刚好我的blog每次都要编译然后提交到github，刚好用它做一个演示。

Travis CI的介绍

Travis CI

是CI / CD生态系统中比较常见的名号之一，最初设定为开源项目，并在多年扩展之后转为闭源项目。它专注于CI工作，通过自动化测试和警报系统提高构建过程的效能。

它有什么作用？

Travis-CI允许用户在部署代码时对代码进行快速测试。它支持代码大小变更，可识别构建与测试中发生的一切变更。检测到变更后，Travis CI可以提供有关变更是否成功的反馈。

开发人员可以使用Travis CI对运行时进行观察，并行运行多项测试，并将该工具与Slack、HipChat以及Email等集成，从而通过多种渠道获取问题或构建失败通知。

Travis CI支持容器构建，并支持Linux Ubuntu和OSX。您可以在不同的编程语言中使用它，例如Java，C＃，Clojure，GO，Haskell，Swift，Perl等等。其具备一份相对有限的第三方集成列表，但由于关注重点在于CI而非CD，因此其可能解决不了您的实际问题。

使用Travsi CI发布Hexo

我的blog使用的是Hexo，它有丰富的模板可以选择，支持markdown写文章再构建生成静态html，所以当时就选用了它。

在做之前我们需要准备一些东西，如下：

Step 1

首先我们要在github上创建一个repository，给这个repository创建两个分支，我这里使用master作为静态html分支，blog-source作为博客源码分支。

ps. 分支名称都随意，有人喜欢用master作为源码分支，gh-pages作为静态html分支，都可以请随意。

Step 2

去github上获取accesstoken，可以去https://github.com/settings/tokens获取，生成一个token（generate new token），token的scope范围看自己的需求选择，我这里选择的是repo下全部。

生成的token记得自己先保存起来，因为刷新页面后你就再也看不到它了，如果忘记了那就去重新生成一个（regenerate token）

图四

图五

Step 3

在blog库的blog-source分支中添加.travis.yml

language: node_js
node_js: 10.16.3
install:
  - npm install
script: bash ./deploy.sh
branches:
  only:
    - blog-source
notifications:
  email: false

hexo采用nodejs开发，所以这里语言选择nodejs，我这里选择nodejs版本是10.16.3，因为高版本nodejs下hexo生成的静态文件有问题，如果是其他的程序可以使用stable。

install阶段执行npm安装依赖。

script阶段执行一个外部脚本，在同.travis.yml路径下创建shell脚本deploy.sh

#!/usr/bin/env sh
# 确保脚本抛出遇到的错误
set -e
# 生成静态文件
hexo generate
# 进入生成的文件夹
cd ./public
#创建.nojekyll 防止Github Pages build错误
touch .nojekyll
git init
git add -A
git commit -m "deploy"
git push -f "https://${access_token}@github.com/ningyu1/blog.git" master:master
cd -

脚本中先执行hexo -g（等同于hexo generate）生成静态html文件，文件生成在当前目录下的public文件夹。

进入到public文件夹下执行git命令，这里需要注意的是使用git push -f强制推送，如果没有设置git user.name和git user.email的话提交的用户是Travis Ci User

ps. 这里特殊说明一下变量 ${access_token}，这里使用travis ci的运行时环境变量，像这种相对重要的信息放到运行时环境变量会安全一些，避免别人拿到我的AccessToken做一些坏事情，哈哈。

Step 4

登录travis-ci，可以使用github三方登录，添加一个github仓库，travis跟github集成的还是非常紧密和方便的，添加仓库可以直接读取github上的仓库，在列表里面找到blog打开使用travis，如图一。

图一

进入dashbord查看刚才添加的库信息，选择More options->Settings，添加Environment Variables

创建一个access_token的环境变量，可以选择那些branch使用，DISPLAY VALUE IN BUILD LOG是控制构建日志中是否要输出变量的值，为了安全起见建议不用开启，如图二

图二

Step 5

travis-ci接收到github的事件请求就会自动触发job。

一切准备就绪之后提交并推送代码到github仓库，这样travis会接收到github的push event事件，可以去More options->Requests中查看接收到的请求信息，如图三

图三

如果没有啥特殊情况看构建日志就可以看到成功信息。

Problem

这里我遇到了一个问题，我使用hexo只支持10.x一下的nodejs版本，刚开始使用的node_js: stable，查看job日志可以看到使用的版本号如下

$ node --version
v14.0.0
$ npm --version
6.14.4
$ nvm --version
0.35.3

v14.x 版本导致hexo生成的html文件都是0 byte，果断的降低了nodejs版本就好了。

相信大家在实际工作中最常遇到的问题就是死锁（dead lock），说到死锁就不得不说先说事务，我们都知道死锁是并发事务时经常会遇到的问题，当然死锁的场景也非常多并且与数据库事务隔离级别有着很大的关系，这些不懂都没有关系，今天我们就花一分钟来理解消化事务的四要素。

事务四要素：ACID

说到事务的四个要素，最容易理解的就是原子性，但是其他三个要素：一致性、隔离性、持久性也是非常重要，恰恰也是经常被人忽视的。

原子性（Atomicity）

原子性非常容易被人理解，直白点说就是一个事务中的所有操作（CRUD）就像是一个原子操作一样不可分割开来，要么全部成功，要么全部失败，不允许部分成功部分失败。

举个例子：

1. 往篮子里放入一个苹果
2. 随后从篮子里拿出一个梨
   这两个动作要么都成功，要么都失败，不存在只往篮子里放苹果而没拿梨，也不存在只从篮子里拿梨而没有放苹果。

原子性的侧重点在于多个动作必须同时成功或者同时失败。

一致性（Consistency）

网上争议最多的就是对一致性的理解，公说公有理婆说婆有理，我觉得还是仁者见仁智者见智。

说法一：事务开始和结束后，数据库的完整性约束没有被破坏，如外键约束。
说法二：一个事务单元需要提交之后才会被其他事务可见。

网上有很多用张三给李四转账的例子来说明一致性，但是看起来感觉跟原子性的概念雷同，这也是经常会有人傻傻分不清一致性和原子性的区别。

说法三：一致性和原子性的区别在于两者的侧重点不同，原子性关注的是状态，要么全部成功，要么全部失败，不存在部分成功的状态。而一致性关注的是数据的可见性，一个事务的中间状态的数据对外部不可见，只有最初状态和最终状态的数据对外可见。

其实这个说法是对的，但是理解起来不通俗易懂甚至有些模糊，很难让人很通俗易懂的明白其中的区别。

而且看到上面区别解释后又会有人提出挑战说，当事务的隔离级别是Read Uncommitted（读未提交）时，可以把事务的中间状态数据对其他事务可见，这个不就是违背了一致性么？

其实事务的隔离级别就是在事务的四要素和性能上面做平衡，有时候为了提高性能，会适度的破坏一致性原则。

这篇文章是我见过对一致性理解最靠谱的。

说回到主题一致性的理解上，我对一致性的理解是这样的，一致性关注的点是数据的操作结果是否与用户业务预期一致，这里有两点需要注意。

1. 一致性关注的是结果状态，什么是结果状态？它是一个要达到的预期效果并非是一个保证手段。而数据库的唯一建、外键、主键等这些约束建和AID原则：原子性（A）、隔离性（I）、持久性（D）以及提交、回滚等动作是保证结果能达到与预期效果一致的手段。
2. 一致性它是由用户的业务决定的并非数据库决定的，网上很多的例子解释一致性都是狭义的理解，为什么这样说的？比如说账户扣钱，如果业务约束账户不允许为负数，那当扣成负数的时候就会通过回滚来保持一致性，如果业务约束账户允许为负数，那当扣成负数也可以正常提交来保持一致性，那这两个最终的状态是完全不一样的，但都是满足用户预先设置好的约束规则，所以一致性是由用户来决定的，从结果来看只要符合业务预期约束就是满足一致性的。

隔离性（Isolation）

并发事务之间不会互相影响，就像串行执行一样，也就是说并发事务之间都是互相隔离的，你不影响我，我也不影响你。
隔离性侧重点是并发事务之间的影响，说到并发事务就要提到数据库的隔离级别，有的时候会通过调整数据库的隔离级别来适度的破坏一致性和隔离性，从而提高数据库处理性能。

ps. 画外音，隔离性是我们需要重点关注的，因为不同的隔离级别，可能对应的加锁过程不一样，而正是因为引入了各种各样的隔离级别，才让锁问题变得格外复杂。解决和分析死锁问题，重点就是要搞清楚数据库的隔离级别。那么隔离级别是个什么东西呢？我们会在后面出单独的文章来重点说明。

持久性（Durability）

持久性就非常好理解了，事务提交后即持久化到磁盘不会丢失。
持久性侧重的是数据不丢失，这个跟网上讨论最多的 （“丢失更新”、“提交覆盖”、“Read-Modify-Write问题”）很容易混淆，看起来效果都是没有存入正确的数据，看起来好像数据丢失了一样。
实际上两者区别很大的，前者是说数据存到物理磁盘不会丢失，而后者则说的是并发事务中的相互影响导致最终的数据结果不同。

总结

这一章我们对事务的ACID进行了快速的理解，这里容易混淆的有原子性和一致性。

1. 原子性的侧重点在于操作完整不可分隔，往篮子里放入一个苹果随后从篮子里拿出一个梨，不存在只往篮子里放入苹果没有拿梨，也不存在只从篮子里拿梨没有放入苹果。
2. 一致性的侧重点在于结果状态是否与用户的预期效果一致。
3. 隔离性的侧重点在于并发事务之间互不影响，切记不是你中有我我中有你。
4. 持久性的侧重点在于数据落盘不丢，切记不是并发事务导致的最终数据结果丢失。

下一章我们会从事务的隔离级别来进行快速学习和掌握，隔离级别会分两章来进行，先让大家搞清楚我们最常挂在嘴边的也是面试最常问道的：脏读、幻读、不可重复度、可重复度、丢失更新的定义和区别，我会尽量用通俗易懂的方式来让大家明白。

附录

这里从网上找了一些关于事务的文章，不用太纠结对错，仁者见仁，智者见智，有句俗话是这样说的：不要太认真，认真你就输了，哈哈。。。。

1. https://www.aneasystone.com/archives/2017/10/solving-dead-locks-one.html
2. https://www.cnblogs.com/autointerface/p/11959711.html
3. http://novoland.github.io/%E6%95%B0%E6%8D%AE%E5%BA%93/2014/07/26/MySQL%E6%80%BB%E7%BB%93.html

ps. 文章中有哪些错误的地方欢迎指正。

好像文章有点长阅读起来超过了一分钟，看来功力还不够没有压缩到一分钟，希望能帮助到需要的人。

Love and peace！

研究 Dubbo 网卡地址注册时的一点思考

1 如何选择合适的网卡地址

可能相当一部分人还不知道我这篇文章到底要讲什么，我说个场景，大家应该就明晰了。在分布式服务调用过程中，以 Dubbo 为例，服务提供者往往需要将自身的 IP 地址上报给注册中心，供消费者去发现。在大多数情况下 Dubbo 都可以正常工作，但如果你留意过 Dubbo 的 github issue，其实有不少人反馈：Dubbo Provider 注册了错误的 IP。如果你能立刻联想到：多网卡、内外网地址共存、VPN、虚拟网卡等关键词，那我建议你一定要继续将本文看下去，因为我也想到了这些，它们都是本文所要探讨的东西！那么“如何选择合适的网卡地址”呢，Dubbo 现有的逻辑到底算不算完备？我们不急着回答它，而是带着这些问题一起进行研究，相信到文末，其中答案，各位看官自有评说。

2 Dubbo 是怎么做的

Dubbo 获取网卡地址的逻辑在各个版本中也是千回百转，走过弯路，也做过优化，我们用最新的 2.7.2-SNAPSHOT 版本来介绍，在看以下源码时，大家可以怀着质疑的心态去阅读，在 dubbo github 的 master 分支可以获取源码。获取 localhost 的逻辑位于 org.apache.dubbo.common.utils.NetUtils#getLocalAddress0() 之中

private static InetAddress getLocalAddress0() {
    InetAddress localAddress = null;
    // 首先尝试获取 /etc/hosts 中 hostname 对应的 IP
    localAddress = InetAddress.getLocalHost();
    Optional<InetAddress> addressOp = toValidAddress(localAddress);
    if (addressOp.isPresent()) {
        return addressOp.get();
    }

    // 没有找到适合注册的 IP，则开始轮询网卡
    Enumeration<NetworkInterface> interfaces = NetworkInterface.getNetworkInterfaces();
    if (null == interfaces) {
        return localAddress;
    }
    while (interfaces.hasMoreElements()) {
        NetworkInterface network = interfaces.nextElement();
        Enumeration<InetAddress> addresses = network.getInetAddresses();
        while (addresses.hasMoreElements()) {
            // 返回第一个匹配的适合注册的 IP
            Optional<InetAddress> addressOp = toValidAddress(addresses.nextElement());
            if (addressOp.isPresent()) {
                return addressOp.get();
            }
        }
    }
    return localAddress;
}

Dubbo 这段选取本地地址的逻辑大致分成了两步

1. 先去 /etc/hosts 文件中找 hostname 对应的 IP 地址，找到则返回；找不到则转 2
2. 轮询网卡，寻找合适的 IP 地址，找到则返回；找不到返回 null，在 getLocalAddress0 外侧还有一段逻辑，如果返回 null，则注册 127.0.0.1 这个本地回环地址

首先强调下，这段逻辑并没有太大的问题，先别急着挑刺，让我们来分析下其中的一些细节，并进行验证。

2.1 尝试获取 hostname 映射 IP

Dubbo 首先选取的是 hostname 对应的 IP，在源码中对应的 InetAddress.getLocalHost(); 在 *nix 系统实际部署 Dubbo 应用时，可以首先使用 hostname 命令获取主机名

xujingfengdeMacBook-Pro:~ xujingfeng$ hostname
xujingfengdeMacBook-Pro.local

紧接着在 /etc/hosts 配置 IP 映射，为了验证 Dubbo 的机制，我们随意为 hostname 配置一个 IP 地址

127.0.0.1localhost
1.2.3.4 xujingfengdeMacBook-Pro.local

接着调用 NetUtils.getLocalAddress0() 进行验证，控制台打印如下：

xujingfengdeMacBook-Pro.local/1.2.3.4

2.2 判定有效的 IP 地址

在 toValidAddress 逻辑中，Dubbo 存在以下逻辑判定一个 IP 地址是否有效

private static Optional<InetAddress> toValidAddress(InetAddress address) {
    if (address instanceof Inet6Address) {
        Inet6Address v6Address = (Inet6Address) address;
        if (isValidV6Address(v6Address)) {
            return Optional.ofNullable(normalizeV6Address(v6Address));
        }
    }
    if (isValidV4Address(address)) {
        return Optional.of(address);
    }
    return Optional.empty();
}

依次校验其符合 Ipv6 或者 Ipv4 的 IP 规范，对于 Ipv6 的地址，见如下代码：

static boolean isValidV6Address(Inet6Address address) {
    boolean preferIpv6 = Boolean.getBoolean("java.net.preferIPv6Addresses");
    if (!preferIpv6) {
        return false;
    }
    try {
        return address.isReachable(100);
    } catch (IOException e) {
        // ignore
    }
    return false;
}

首先获取 java.net.preferIPv6Addresses 参数，其默认值为 false，鉴于大多数应用并没有使用 Ipv6 地址作为理想的注册 IP，这问题不大，紧接着通过 isReachable 判断网卡的连通性。例如一些网卡可能是 VPN/虚拟网卡的地址，如果没有配置路由表，往往无法连通，可以将之过滤。

对于 Ipv4 的地址，见如下代码：

static boolean isValidV4Address(InetAddress address) {
    if (address == null || address.isLoopbackAddress()) {
        return false;
    }
    String name = address.getHostAddress();
    boolean result = (name != null
            && IP_PATTERN.matcher(name).matches()
            && !Constants.ANYHOST_VALUE.equals(name)
            && !Constants.LOCALHOST_VALUE.equals(name));
    return result;
}

对比 Ipv6 的判断，这里我们已经发现前后不对称的情况了

• Ipv4 相比 Ipv6 的逻辑多了 Ipv4 格式的正则校验、本地回环地址校验、ANYHOST 校验
• Ipv4 相比 Ipv6 的逻辑少了网卡连通性的校验

大家都知道，Ipv4 将 127.0.0.1 定为本地回环地址， Ipv6 也存在回环地址：0:0:0:0:0:0:0:1 或者表示为 ::1。改进建议也很明显，我们放到文末统一总结。

2.3 轮询网卡

如果上述地址获取为 null 则进入轮询网卡的逻辑（例如 hosts 未指定 hostname 的映射或者 hostname 配置成了 127.0.0.1 之类的地址便会导致获取到空的网卡地址），轮询网卡对应的源码是 NetworkInterface.getNetworkInterfaces() ，这里面涉及的知识点就比较多了，支撑起了我写这篇文章的素材，Dubbo 的逻辑并不复杂，进行简单的校验，返回第一个可用的 IP 即可。

性子急的读者可能忍不住了，多网卡！合适的网卡可能不止一个，Dubbo 怎么应对呢？按道理说，我们也替 Dubbo 说句公道话，客官要不你自己指定下？我们首先得对多网卡的场景达成一致看法，才能继续把这篇文章完成下去：我们只能尽可能过滤那些“不对”的网卡。Dubbo 看样子对所有网卡是一视同仁了，那么是不是可以尝试优化一下其中的逻辑呢？

许多开源的服务治理框架在 stackoverflow 或者其 issue 中，注册错 IP 相关的问题都十分高频，大多数都是轮询网卡出了问题。既然事情发展到这儿，势必需要了解一些网络、网卡的知识，我们才能过滤掉那些明显不适合 RPC 服务注册的 IP 地址了。

3 Ifconfig 介绍

我并没有想要让大家对后续的内容望而却步，特地选择了这个大家最熟悉的 Linux 命令！对于那些吐槽：“天呐，都 2019 年了，你怎么还在用 net-tools/ifconfig，iproute2/ip 了解一下”的言论，请大家视而不见。无论你使用的是 mac，还是 linux，都可以使用它去 CRUD 你的网卡配置。

3.1 常用指令

启动关闭指定网卡：

ifconfig eth0 up
ifconfig eth0 down

ifconfig eth0 up 为启动网卡 eth0，ifconfig eth0 down 为关闭网卡 eth0。ssh 登陆 linux 服务器操作的用户要小心执行这个操作了，千万不要蠢哭自己。不然你下一步就需要去 google：“禁用 eth0 网卡后如何远程连接 Linux 服务器” 了。

为网卡配置和删除IPv6地址：

ifconfig eth0 add 33ffe:3240:800:1005::2/64    #为网卡eth0配置IPv6地址
ifconfig eth0 del 33ffe:3240:800:1005::2/64    #为网卡eth0删除IPv6地址

用 ifconfig 修改 MAC 地址：

ifconfig eth0 hw ether 00:AA:BB:CC:dd:EE

配置 IP 地址：

[root@localhost ~]# ifconfig eth0 192.168.2.10
[root@localhost ~]# ifconfig eth0 192.168.2.10 netmask 255.255.255.0
[root@localhost ~]# ifconfig eth0 192.168.2.10 netmask 255.255.255.0 broadcast 192.168.2.255

启用和关闭arp协议：

ifconfig eth0 arp    #开启网卡eth0 的arp协议
ifconfig eth0 -arp   #关闭网卡eth0 的arp协议

设置最大传输单元：

ifconfig eth0 mtu 1500    #设置能通过的最大数据包大小为 1500 bytes

3.2 查看网卡信息

在一台 ubuntu 上执行 ifconfig -a

ubuntu@VM-30-130-ubuntu:~$ ifconfig -a
eth0      Link encap:Ethernet  HWaddr 52:54:00:a9:5f:ae
          inet addr:10.154.30.130  Bcast:10.154.63.255  Mask:255.255.192.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:149673 errors:0 dropped:0 overruns:0 frame:0
          TX packets:152271 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:15205083 (15.2 MB)  TX bytes:21386362 (21.3 MB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          
docker0   Link encap:Ethernet  HWaddr 02:42:58:45:c1:15
          inet addr:172.17.0.1  Bcast:172.17.255.255  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

为了防止黑客对我的 Linux 发起攻击，我还是偷偷对 IP 做了一点“改造”，请不要为难一个趁着打折+组团购买廉价云服务器的小伙子。对于部分网卡的详细解读:

eth0 表示第一块网卡， 其中 HWaddr 表示网卡的物理地址，可以看到目前这个网卡的物理地址(MAC 地址）是 02:42:38:52:70:54

inet addr 用来表示网卡的 IP 地址，此网卡的 IP 地址是 10.154.30.130，广播地址， Bcast: 172.18.255.255，掩码地址 Mask:255.255.0.0

lo 是表示主机的回环地址，这个一般是用来测试一个网络程序，但又不想让局域网或外网的用户能够查看，只能在此台主机上运行和查看所用的网络接口。比如把 HTTPD 服务器的指定到回坏地址，在浏览器输入 127.0.0.1 就能看到你所架构的 WEB 网站了。但只有你能看得到，局域网的其它主机或用户则无从知晓。

第一行：连接类型：Ethernet（以太网）HWaddr（硬件mac地址）

第二行：网卡的IP地址、子网、掩码

第三行：UP（代表网卡开启状态）RUNNING（代表网卡的网线被接上）MULTICAST（支持组播）MTU:1500（最大传输单元）：1500字节（ifconfig 不加 -a 则无法看到 DOWN 的网卡）

第四、五行：接收、发送数据包情况统计

第七行：接收、发送数据字节数统计信息。

紧接着的两个网卡 docker0，tun0 是怎么出来的呢？我在我的 ubuntu 上装了 docker 和 openvpn。这两个东西应该是日常干扰我们做服务注册时的罪魁祸首了，当然，也有可能存在 eth1 这样的第二块网卡。ifconfig -a 看到的东西就对应了 JDK 的 api ：NetworkInterface.getNetworkInterfaces() 。我们简单做个总结，大致有三个干扰因素

• 以 docker 网桥为首的虚拟网卡地址，毕竟这东西这么火，怎么也得单独列出来吧？
• 以 TUN/TAP 为代表的虚拟网卡地址，多为 VPN 场景
• 以 eth1 为代表的多网卡场景，有钱就可以装多网卡了！

我们后续的篇幅将针对这些场景做分别的介绍，力求让大家没吃过猪肉，起码看下猪怎么跑的。

4 干扰因素一：Docker 网桥

熟悉 docker 的朋友应该知道 docker 会默认创建一个 docker0 的网桥，供容器实例连接。如果嫌默认的网桥不够直观，我们可以使用 bridge 模式自定义创建一个新的网桥：

ubuntu@VM-30-130-ubuntu:~$ docker network create kirito-bridge
a38696dbbe58aa916894c674052c4aa6ab32266dcf6d8111fb794b8a344aa0d9
ubuntu@VM-30-130-ubuntu:~$ ifconfig -a
br-a38696dbbe58 Link encap:Ethernet  HWaddr 02:42:6e:aa:fd:0c
          inet addr:172.19.0.1  Bcast:172.19.255.255  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

使用 docker network 指令创建网桥之后，自动创建了对应的网卡，我只给出了 ifconfig -a 的增量返回部分，可以看出多了一个 br-a38696dbbe58 的网卡。

我有意区分了“网桥”和“网卡”，可以使用 bridge-utils/brctl 来查看网桥信息：

ubuntu@VM-30-130-ubuntu:~$ sudo brctl show
bridge namebridge idSTP enabledinterfaces
br-a38696dbbe588000.02426eaafd0cno
docker08000.02425845c215no

网桥是一个虚拟设备，这个设备只有 brctl show 能看到，网桥创建之后，会自动创建一个同名的网卡，并将这个网卡加入网桥。

5 干扰因素二：TUN/TAP 虚拟网络设备

平时我们所说的虚拟网卡、虚拟机，大致都跟 TUN/TAP 有关。我的读者大多数是 Java 从业者，相信我下面的内容并没有太超纲，不要被陌生的名词唬住。对于被唬住的读者，也可以直接跳过 5.1~5.3，直接看 5.4 的实战。

5.1 真实网卡工作原理

1918847-496d0e96c237f25a

上图中的 eth0 表示我们主机已有的真实的网卡接口 (interface)。

网卡接口 eth0 所代表的真实网卡通过网线(wire)和外部网络相连，该物理网卡收到的数据包会经由接口 eth0 传递给内核的网络协议栈(Network Stack)。然后协议栈对这些数据包进行进一步的处理。

对于一些错误的数据包,协议栈可以选择丢弃；对于不属于本机的数据包，协议栈可以选择转发；而对于确实是传递给本机的数据包,而且该数据包确实被上层的应用所需要，协议栈会通过 Socket API 告知上层正在等待的应用程序。

5.2 TUN 工作原理

1918847-85ea08bc89d9427e

我们知道，普通的网卡是通过网线来收发数据包的话，而 TUN 设备比较特殊，它通过一个文件收发数据包。

如上图所示，tunX 和上面的 eth0 在逻辑上面是等价的， tunX 也代表了一个网络接口,虽然这个接口是系统通过软件所模拟出来的.

网卡接口 tunX 所代表的虚拟网卡通过文件 /dev/tunX 与我们的应用程序(App)相连，应用程序每次使用 write 之类的系统调用将数据写入该文件，这些数据会以网络层数据包的形式，通过该虚拟网卡，经由网络接口 tunX 传递给网络协议栈，同时该应用程序也可以通过 read 之类的系统调用，经由文件 /dev/tunX 读取到协议栈向 tunX 传递的所有数据包。

此外，协议栈可以像操纵普通网卡一样来操纵 tunX 所代表的虚拟网卡。比如说，给 tunX 设定 IP 地址，设置路由，总之，在协议栈看来，tunX 所代表的网卡和其他普通的网卡区别不大，当然，硬要说区别，那还是有的,那就是 tunX 设备不存在 MAC 地址，这个很好理解，tunX 只模拟到了网络层，要 MAC地址没有任何意义。当然，如果是 tapX 的话，在协议栈的眼中，tapX 和真实网卡没有任何区别。

是不是有些懵了？我是谁，为什么我要在这篇文章里面学习 TUN！因为我们常用的 VPN 基本就是基于 TUN/TAP 搭建的，如果我们使用 TUN 设备搭建一个基于 UDP 的 VPN ，那么整个处理过程可能是这幅样子：

1918847-ac4155ec7e9489b2

5.3 TAP 工作原理

TAP 设备与 TUN 设备工作方式完全相同，区别在于：

1. TUN 设备是一个三层设备，它只模拟到了 IP 层，即网络层 我们可以通过 /dev/tunX 文件收发 IP 层数据包，它无法与物理网卡做 bridge，但是可以通过三层交换（如 ip_forward）与物理网卡连通。可以使用ifconfig之类的命令给该设备设定 IP 地址。
2. TAP 设备是一个二层设备，它比 TUN 更加深入，通过 /dev/tapX 文件可以收发 MAC 层数据包，即数据链路层，拥有 MAC 层功能，可以与物理网卡做 bridge，支持 MAC 层广播。同样的，我们也可以通过ifconfig之类的命令给该设备设定 IP 地址，你如果愿意，我们可以给它设定 MAC 地址。

关于文章中出现的二层，三层，我这里说明一下，第一层是物理层，第二层是数据链路层，第三层是网络层，第四层是传输层。

5.4 openvpn 实战

openvpn 是 Linux 上一款开源的 vpn 工具，我们通过它来复现出影响我们做网卡选择的场景。

安装 openvpn

sudo apt-get install openvpn

安装一个 TUN 设备：

ubuntu@VM-30-130-ubuntu:~$ sudo openvpn --mktun --dev tun0
Mon Apr 29 22:23:31 2019 TUN/TAP device tun0 opened
Mon Apr 29 22:23:31 2019 Persist state set to: ON

安装一个 TAP 设备：

ubuntu@VM-30-130-ubuntu:~$ sudo openvpn --mktun --dev tap0
Mon Apr 29 22:24:36 2019 TUN/TAP device tap0 opened
Mon Apr 29 22:24:36 2019 Persist state set to: ON

执行 ifconfig -a 查看网卡，只给出增量的部分：

tap0      Link encap:Ethernet  HWaddr 7a:a2:a8:f1:6b:df
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.154.30.131  P-t-P:10.154.30.131  Mask:255.255.255.255
          UP POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

这样就解释了文章一开始为什么会有 tun0 这样的网卡了。这里读者可能会有疑惑，使用 ifconfig 不是也可以创建 tap 和 tun 网卡吗？当然啦，openvpn 是一个 vpn 工具，只能创建名为 tunX/tapX 的网卡，其遵守着一定的规范，ifconfig 可以随意创建，但没人认那些随意创建的网卡。

6 干扰因素三：多网卡

image-20190429223515625

这个没有太多好说的，有多张真实的网卡，从普哥那儿搞到如上的 IP 信息。

7 MAC 下的差异

虽然 ifconfig 等指令是 *nux 通用的，但是其展示信息，网卡相关的属性和命名都有较大的差异。例如这是我 MAC 下执行 ifconfig -a 的返回：

xujingfengdeMacBook-Pro:dubbo-in-action xujingfeng$ ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
XHC0: flags=0<> mtu 0
XHC20: flags=0<> mtu 0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 88:e9:fe:88:a0:76
inet6 fe80::1cab:f689:60d1:bacb%en0 prefixlen 64 secured scopeid 0x6
inet 30.130.11.242 netmask 0xffffff80 broadcast 30.130.11.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
ether 0a:e9:fe:88:a0:76
media: autoselect
status: inactive
awdl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1484
ether 66:d2:8c:8c:dd:85
inet6 fe80::64d2:8cff:fe8c:dd85%awdl0 prefixlen 64 scopeid 0x8
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=60<TSO4,TSO6>
ether aa:00:d0:13:0e:01
media: autoselect <full-duplex>
status: inactive
en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=60<TSO4,TSO6>
ether aa:00:d0:13:0e:00
media: autoselect <full-duplex>
status: inactive
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=63<RXCSUM,TXCSUM,TSO4,TSO6>
ether aa:00:d0:13:0e:01
Configuration:
id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
ipfilter disabled flags 0x2
member: en1 flags=3<LEARNING,DISCOVER>
        ifmaxaddr 0 port 9 priority 0 path cost 0
member: en2 flags=3<LEARNING,DISCOVER>
        ifmaxaddr 0 port 10 priority 0 path cost 0
nd6 options=201<PERFORMNUD,DAD>
media: <unknown type>
status: inactive
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
inet6 fe80::3fe0:3e8b:384:9968%utun0 prefixlen 64 scopeid 0xc
nd6 options=201<PERFORMNUD,DAD>
utun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::7894:3abc:5abd:457d%utun1 prefixlen 64 scopeid 0xd
nd6 options=201<PERFORMNUD,DAD>

内容很多，我挑几点差异简述下：

• 内容展示形式不一样，没有 Linux 下的接收、发送数据字节数等统计信息

• 真实网卡的命名不一样：eth0 -> en0

• 虚拟网卡的命名格式不一样：tun/tap -> utun

对于这些常见网卡命名的解读，我摘抄一部分来自 stackoverflow 的回答：

In arbitrary order of my familarity / widespread relevance:

lo0 is loopback.

en0 at one point “ethernet”, now is WiFi (and I have no idea what extra en1 or en2 are used for).

fw0 is the FireWire network interface.

stf0 is an IPv6 to IPv4 tunnel interface) to support the transition from IPv4 to the IPv6 standard.

gif0 is a more generic tunneling interface) [46]-to-[46].

awdl0 is Apple Wireless Direct Link

p2p0 is related to AWDL features. Either as an old version, or virtual interface with different semantics than awdl.

the “Network” panel in System Preferences to see what network devices “exist” or “can exist” with current configuration.

many VPNs will add additional devices, often “utun#” or “utap#” following TUN/TAP (L3/L2)virtual networking devices.

use netstat -nr to see how traffic is currently routed via network devices according to destination.

interface naming conventions started in BSD were retained in OS X / macOS, and now there also additions.

8 Dubbo 改进建议

我们进行了以上探索，算是对网卡有一点了解了。回过头来看看 Dubbo 获取网卡的逻辑，是否可以做出改进呢？

Dubbo Action 1:

保持 Ipv4 和 Ipv6 的一致性校验。为 Ipv4 增加连通性校验；为 Ipv6 增加 LoopBack 和 ANYHOST 等校验。

Dubbo Action 2:

NetworkInterface network = interfaces.nextElement();
if (network.isLoopback() || network.isVirtual() || !network.isUp()) {
    continue;
}

JDK 提供了以上的 API，我们可以利用起来，过滤一部分一定不正确的网卡。

Dubbo Action 3:

我们本文花了较多的篇幅介绍了 docker 和 TUN/TAP 两种场景导致的虚拟网卡的问题，算是较为常见的一个影响因素，虽然他们的命名具有固定性，如 docker0、tunX、tapX，但我觉得通过网卡名称的判断方式去过滤注册 IP 有一些 hack，所以不建议 dubbo contributor 提出相应的 pr 去增加这些 hack 判断，尽管可能会对判断有所帮助。

对于真实多网卡、内外网 IP 共存的场景，不能仅仅是框架层在做努力，用户也需要做一些事，就像爱情一样，我可以主动一点，但你也得反馈，才能发展出故事。

Dubbo User Action 1:

可以配置 /etc/hosts 文件，将 hostname 对应的 IP 显式配置进去。

Dubbo User Action 2:

可以使用启动参数去显式指定注册的 IP：

-DDUBBO_IP_TO_REGISTRY=1.2.3.4

也可以指定 Dubbo 服务绑定在哪块网卡上：

-DDUBBO_IP_TO_BIND=1.2.3.4

9 参考文章

TUN/TAP 设备浅析

what-are-en0-en1-p2p-and-so-on-that-are-displayed-after-executing-ifconfig

原文地址 | 纠错

我们可以点击上面的文章链接进去回顾一下具体的问题。

问题分析

错误是出在cas ticket cookie在cas server服务端验证时出现了问题，这里解释一下这个问题现象。

当我们cas server部署两台服务时，前端采用nginx做负载均衡，当我们访问cas server的时候nginx会随机选择一个服务端返回给前端，因此在第一次登陆的时候是由serverA生成的ticket，ticket中包含了客户端ip，当下次访问时路由到serverB时ticket验证的时候获取的客户端ip不一致导致的问题。

重点是在类：org.apereo.cas.web.support.DefaultCasCookieValueManager.obtainCookieValue方法

这里以cas server5.0.4版本为例看一下源码：

public String obtainCookieValue(final Cookie cookie, final HttpServletRequest request) {
       final String cookieValue = this.cipherExecutor.decode(cookie.getValue());
       LOGGER.debug("Decoded cookie value is [{}]", cookieValue);
       if (StringUtils.isBlank(cookieValue)) {
           LOGGER.debug("Retrieved decoded cookie value is blank. Failed to decode cookie [{}]", cookie.getName());
           return null;
       }

       final String[] cookieParts = cookieValue.split(String.valueOf(COOKIE_FIELD_SEPARATOR));
       if (cookieParts.length != COOKIE_FIELDS_LENGTH) {
           throw new IllegalStateException("Invalid cookie. Required fields are missing");
       }
       final String value = cookieParts[0];
       final String remoteAddr = cookieParts[1];
       final String userAgent = cookieParts[2];

       if (StringUtils.isBlank(value) || StringUtils.isBlank(remoteAddr)
               || StringUtils.isBlank(userAgent)) {
           throw new IllegalStateException("Invalid cookie. Required fields are empty");
       }

       if (!remoteAddr.equals(request.getRemoteAddr())) {
           throw new IllegalStateException("Invalid cookie. Required remote address does not match "
                   + request.getRemoteAddr());
       }

       final String agent = WebUtils.getHttpServletRequestUserAgent(request);
       if (!userAgent.equals(agent)) {
           throw new IllegalStateException("Invalid cookie. Required user-agent does not match " + agent);
       }
       return value;
   }

我们可以看出在ticket解决之后进行验证时获取的客户端ip是从：request.getRemoteAddr()获取的，这种方式获取在4、7层负载均衡的时候是无法获取真实的客户端ip。

接下来我们再看一下生成ticket的规则代码：

public String buildCookieValue(final String givenCookieValue, final HttpServletRequest request) {
       final StringBuilder builder = new StringBuilder(givenCookieValue);

       final ClientInfo clientInfo = ClientInfoHolder.getClientInfo();
       builder.append(COOKIE_FIELD_SEPARATOR);
       builder.append(clientInfo.getClientIpAddress());
       
       final String userAgent = WebUtils.getHttpServletRequestUserAgent(request);
       if (StringUtils.isBlank(userAgent)) {
           throw new IllegalStateException("Request does not specify a user-agent");
       }
       builder.append(COOKIE_FIELD_SEPARATOR);
       builder.append(userAgent);

       final String res = builder.toString();
       LOGGER.debug("Encoding cookie value [{}]", res);
       return this.cipherExecutor.encode(res);
   }

ticket的生成是从clientInfo.getClientIpAddress()获取客户端ip

我们再看org.apereo.inspektr.common.web.ClientInfo

public ClientInfo(final HttpServletRequest request,
                      final String alternateServerAddrHeaderName,
                      final String alternateLocalAddrHeaderName,
                      final boolean useServerHostAddress) {

        try {
            String serverIpAddress = request != null ? request.getLocalAddr() : null;
            String clientIpAddress = request != null ? request.getRemoteAddr() : null;

            if (request != null) {
                if (useServerHostAddress) {
                    serverIpAddress = Inet4Address.getLocalHost().getHostAddress();
                } else if (alternateServerAddrHeaderName != null && !alternateServerAddrHeaderName.isEmpty()) {
                    serverIpAddress = request.getHeader(alternateServerAddrHeaderName) != null
                            ? request.getHeader(alternateServerAddrHeaderName) : request.getLocalAddr();
                }

                if (alternateLocalAddrHeaderName != null && !alternateLocalAddrHeaderName.isEmpty()) {
                    clientIpAddress = request.getHeader(alternateLocalAddrHeaderName) != null ? request.getHeader
                            (alternateLocalAddrHeaderName) : request.getRemoteAddr();
                }
            }

            this.serverIpAddress = serverIpAddress == null ? "unknown" : serverIpAddress;
            this.clientIpAddress = clientIpAddress == null ? "unknown" : clientIpAddress;

        } catch (final Exception e) {
            throw new RuntimeException(e);
        }
    }

从中看出5.0.4版本支持了传入header的来自定义客户端ip获取

但是5.0.4依然有问题它没有改全，从上面的ticket生成逻辑(org.apereo.cas.web.support.DefaultCasCookieValueManager)中可以看出来，生成的时候是通过：clientInfo.getClientIpAddress()，但是验证的时候是通过：request.getRemoteAddr()获取验证的，所以只要加了4,7层负载的话就会存在这个问题。

以上就是整个问题的分析过程，接下来看我们怎么来解决这个问题。

解决方案

cas在tikcet生成与验证的时候都有配置项提供自定义。

只要我们关闭ticket加解密就可以规避这个问题，但是安全性上稍微低一些，如果不想关闭ticket加解密休需要修改配置和代码。

1. 如果开启cas.tgc.cipherEnabled=true

   1. 需要同时多台server配置相同的cas.tgc.signingKey、cas.tgc.encryptionKey保证cookie加解密秘钥相同

   2. 修改代码让验证cookie获取客户端ip保持一致，如果是cas server 5.0.4版本可以修改org.apereo.cas.audit.spi.config.CasCoreAuditConfiguration类中的org.apereo.inspektr.common.web.ClientInfoThreadLocalFilter增加初始化参数来自定义客户端ip获取headerName

   3. @Bean public FilterRegistrationBean casClientInfoLoggingFilter() { final FilterRegistrationBean bean = new FilterRegistrationBean(); bean.setFilter(new ClientInfoThreadLocalFilter()); bean.setUrlPatterns(Collections.singleton("/*")); bean.setName("CAS Client Info Logging Filter"); bean.addInitParameter(ClientInfoThreadLocalFilter.CONST_IP_ADDRESS_HEADER,"X-Forwarded-For"); return bean; }

   4. 修改org.apereo.cas.web.support.DefaultCasCookieValueManager.obtainCookieValue代码，保持生成tikcet和验证ticket时获取客户端ip都使用clientInfo.getClientIpAddress()

2. 关闭cas tgc的加解密：cas.tgc.cipherEnabled=false，牺牲安全性就可以规避这个问题

建议使用配置的方式来调整，这样可以充分的发挥集群的功能。

世界和平、Keep Real！

​ Tomcat在升级版本时遇到的一些问题，在升级tomcat版本后发现原有的功能莫名其妙的出现了错误，我们接下来看一下具体的问题以及分析一下具体的原因

问题分析

我们来具体看一下报错的请求报文

http://localhost:8080/xx-rest/v1/report/salesOrder?
salesStatusList[]=&orderStatus=&salesTypeList[]=&itIsClose=&salesNo=&warehouseNo=&orderNo=&referenceNo=
&skuName=&skuBarcode=&shopNoList[]=&creTimeBeg=2019-06-21+00:00:00&creTimeEnd=2019-06-21+23:59:59
&platformOrderTimeBeg=&platformOrderTimeEnd=&endFinishTimeBeg=&endFinishTimeEnd=
&page=1&pageSize=50&customerNo=&__preventCache=1561084397458

调用后返回的是400的错误，并且进行了测试，当请求参数中存在[]时就会发生错误，去掉后可正常访问

我们查看到后台的错误具体如下：

2019/6/21 上午11:48:052019-06-21 11:48:05.590 [http-apr-8080-exec-3] INFO com.xxx.doFilter(CORSFilter.java:75) - CORS filter >>>>>> Because host:xxx.domain.com and origin:https://xxx.domain.com so Access-Control-Allow-Origin:https://xxx.domain.com
2019/6/21 上午11:48:05Jun 21, 2019 11:48:05 AM org.apache.coyote.http11.AbstractHttp11Processor process
2019/6/21 上午11:48:05INFO: Error parsing HTTP request header
2019/6/21 上午11:48:05 Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
2019/6/21 上午11:48:05java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
2019/6/21 上午11:48:05    at org.apache.coyote.http11.InternalAprInputBuffer.parseRequestLine(InternalAprInputBuffer.java:240)
2019/6/21 上午11:48:05    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1052)
2019/6/21 上午11:48:05    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
2019/6/21 上午11:48:05    at org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:2492)
2019/6/21 上午11:48:05    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
2019/6/21 上午11:48:05    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
2019/6/21 上午11:48:05    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
2019/6/21 上午11:48:05    at java.lang.Thread.run(Thread.java:748)

非法参数：Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986

意思说的是请求中包含了无效的字符，具体去看RFC 7230 and RFC 3986规范中的字符定义。

这个问题很纳闷！因为以前是没有遇到过的，于是先去看tomcat对RFC 7230 and RFC 3986规范的支持情况。

Tomcat从 7.0.73, 8.0.39, 8.5.7 版本后添加了对Url的限制，遵循的就是RFC 7230 and RFC 3986规范。那我们就先搞清楚规范中描述的是什么。

[RFC 3986]

https://www.ietf.org/rfc/rfc3986.txt

我们只需关注规范中字符定义这块，我截图的地方

意思说的是规范中定义url中只允许包含英文字母(a-zA-Z)、数字(0-9)、-_.~四个特殊字符，保留字符用作特定领域分隔符，如果url中有用到需要进行转义

保留的字符有：! * ’ ( ) ; : @ & = + $ , / ? # [ ]

我们知道了RFC3986规范中的定义和tomcat支持规范的版本后问题就很明了了，我们来看一下我们使用的tomcat版本具体是多少，经过查看具体如下：

问题就出在这里，我们使用的tomcat版本刚好是遵循RFC3986规范的tomcat版本。

解决办法

知道了原因之后，具体的解决办法就比较明确了，大概有以下几种：

1. 对请求编码解码。 encodeURI，decodeURI，但是有的时候参数名中出现保留字符是比较麻烦的，需要对参数名进行转义，后台再解析参数时需要先对参数名解码后再通过参数名获取具体参数值
2. tomcat降版本到7.0.73以下，这个是比较好操作的

​ 有时我们在做开发的时候需要记录每个任务执行时间，或者记录一段代码执行时间，最简单的方法就是打印当前时间与执行完时间的差值，然后这样如果执行大量测试的话就很麻烦，并且不直观，如果想对执行的时间做进一步控制，则需要在程序中很多地方修改，目前spring-framework提供了一个StopWatch类可以做类似任务执行时间控制，也就是封装了一个对开始时间，结束时间记录工具

示例

我们来看几个示例

统计输出总耗时

import org.springframework.util.StopWatch;
 
public class SpringStopWatchExample {
 
    public static void main (String[] args) throws InterruptedException {
        StopWatch sw = new StopWatch();
        sw.start();
        //long task simulation
        Thread.sleep(1000);
        sw.stop();
        System.out.println(sw.getTotalTimeMillis());
    }
}

输出

1013

输出最后一个任务的耗时

public class SpringStopWatchExample2 {
 
    public static void main (String[] args) throws InterruptedException {
        StopWatch sw = new StopWatch();
        sw.start("A");//setting a task name
        //long task simulation
        Thread.sleep(1000);
        sw.stop();
        System.out.println(sw.getLastTaskTimeMillis());
    }
}

输出

1009

以优雅的格式打出所有任务的耗时以及占比

import org.springframework.util.StopWatch;
 
public class SpringStopWatchExample3 {
 
    public static void main (String[] args) throws InterruptedException {
        StopWatch sw = new StopWatch();
        sw.start("A");
        Thread.sleep(500);
        sw.stop();
        sw.start("B");
        Thread.sleep(300);
        sw.stop();
        sw.start("C");
        Thread.sleep(200);
        sw.stop();
        System.out.println(sw.prettyPrint());
    }
}

输出

StopWatch '': running time (millis) = 1031
-----------------------------------------
ms     %     Task name
-----------------------------------------
00514  050%  A
00302  029%  B
00215  021%  C

序列服务输出耗时信息

@Override
public long nextSeq(String name) {
    StopWatch watch = new StopWatch();
    watch.start("单序列获取总消耗");
    long sequence = generator.generateId(name);
    watch.stop();
    logger.info(watch.prettyPrint());
    return sequence;
}

更多用法

不同的打印结果

1. getTotalTimeSeconds() 获取总耗时秒，同时也有获取毫秒的方法
2. prettyPrint() 优雅的格式打印结果，表格形式
3. shortSummary() 返回简短的总耗时描述
4. getTaskCount() 返回统计时间任务的数量
5. getLastTaskInfo().getTaskName() 返回最后一个任务TaskInfo对象的名称
   更多查看文档

总结

以后我们统计代码执行效率建议大家都使用这个工具来进行输出，不需要在starttime、endtime再相减计算，用优雅的方式来完成这件事情。

在使用Mybatis分页插件时经常会遇到Mybatis生成的count语句效率很低，今天我们就看一下Mybatis中的countsql的生成逻辑是什么，为何会生成低效的countsql，怎么写sql可以避免低效countsql。

源码分析

com.github.pagehelper.parser.CountSqlParser

/**
 * 将sql转换为count查询
 *
 * @param select
 */
public void sqlToCount(Select select) {
    SelectBody selectBody = select.getSelectBody();
    // 是否能简化count查询
    if (selectBody instanceof PlainSelect && isSimpleCount((PlainSelect) selectBody)) {
        ((PlainSelect) selectBody).setSelectItems(COUNT_ITEM);
    } else {
        PlainSelect plainSelect = new PlainSelect();
        SubSelect subSelect = new SubSelect();
        subSelect.setSelectBody(selectBody);
        subSelect.setAlias(TABLE_ALIAS);
        plainSelect.setFromItem(subSelect);
        plainSelect.setSelectItems(COUNT_ITEM);
        select.setSelectBody(plainSelect);
    }
}
 
/**
 * 是否可以用简单的count查询方式
 *
 * @param select
 * @return
 */
public boolean isSimpleCount(PlainSelect select) {
    //包含group by的时候不可以
    if (select.getGroupByColumnReferences() != null) {
        return false;
    }
    //包含distinct的时候不可以
    if (select.getDistinct() != null) {
        return false;
    }
    for (SelectItem item : select.getSelectItems()) {
        //select列中包含参数的时候不可以，否则会引起参数个数错误
        if (item.toString().contains("?")) {
            return false;
        }
        //如果查询列中包含函数，也不可以，函数可能会聚合列
        if (item instanceof SelectExpressionItem) {
            if (((SelectExpressionItem) item).getExpression() instanceof Function) {
                return false;
            }
        }
    }
    return true;
}

总结

看代码比较清晰明了，话不多说，总结如下：

1. sql包含group by的时候，会生成带子查询的低效countsql
2. sql包含distinct的时候，会生成带子查询的低效countsql
3. sql的列中包含参数的时候，会生成带子查询的低效countsql
4. sql的列中包含函数的时候，会生成带子查询的低效countsql

pagehelper官方最新版更新到了：5.1.6

5.1.5版本有一个优化是对函数进行区分，如果是聚合函数生成带子查询的countsql，如果非聚合函数生成简单的countsql。

具体可以查看：V5.1.5 changelog

看了一下4.2.1 —— 5.1.6之间的版本，除了5.1.5支持了函数区分的支持以外，其他版本没有countsql生成相关的优化，所以sql中包含group by、distinct、列中包含参数，聚合函数会生成低效的countsql。

在使用Mybatis分页插件PageHelper的时候我相信或多或少都会遇到这样的问题，明明没有分页的语句执行后sql语句被自动添加了limit ？,?，看起来非常的莫名其妙，其实这个问题非常明确，就是Java基本功的问题，由于开发使用的是pagehelper.startPage方式，弄出这个问题就是对pagehelper的分页原理不理解而导致的。

首先我们先介绍一下Mybatis的分页用法。

Mybatis分页用法

RowBounds用法

显示的使用RowBounds参数，这种方法是最安全的，在经过Mybatis处理的时候会根据RowBounds参数来自动添加limit表达式，但是这种方法有个缺点，就是需要分页的方法都要增加RowBounds这个参数，其实也很正常，这也是最原始的用法，只是现在开发被惯叼了，又想少写代码又想使用最全的功能。

PageHelper用法

使用pagehelper，这个是一个使用率最高的Mybatis分页插件，使用起来也比较方便，但是包装了很多高级的功能需要理解他的机制，要不然很容易写出bug，例如这次的问题，sql中明明没有使用分页，但是最后执行的sql语句中多了limit。

pagehelper的4.x以上的版本使用pageHelper.startPage方法来进行分页，这种方法是在需要执行的sql之前调用一次，例如：

PageHelper.startPage(1, 10);
list = countryMapper.selectIf(param1);

PageHelper优缺点

优点：

1. 使用简单
2. 对sql无侵入

缺点：

1. 不是及其安全的方式（至少跟采用RowBounds参数进行分页的方式来比较）

PageHelper分页原理

PageHelper采用ThreadLocal来进行分页标识设置，pagehelper保证的是当代码执行到Executor 方法时出现错误，它会在finally快中清理ThreadLocal中的分页标识，如果代码没有执行到Executor方法就出现异常，那就会造成ThreadLocal污染。
当我们执行PageHelper.startPage(1, 10);这一行的时候，其实是在当前线程的ThreadLocal中设置了分页的变量，当执行到countryMapper.selectIf(param1);的时候会通过Executor拦截，从ThreadLocal中获取分页标记，如果存在分页标记就在当前执行的sql语句中增加分页表达式，当Executor拦截执行的时候finally中会清理ThreadLocal中的分页变量。

问题分析

接下来让我们看一下出现的错误

2019-03-28 00:00:00.150 [DubboServerHandler-xx.xx.xx.xx:yyyy-thread-191] DEBUG org.apache.ibatis.logging.jdbc.BaseJdbcLogger.debug(BaseJdbcLogger.java:139) - ==>  Preparing: SELECT id, job...skipping...
### The error may involve xx.yy.zz.XXXXMapper.loadExpress-Inline
### The error occurred while setting parameters
### SQL: select     field as fieldName   from table where field= ?    order by id ASC limit 1 limit ?,?
### Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'limit 0,50' at line 5
; bad SQL grammar []; nested exception is com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'limit 0,50' at line 5, dubbo version: 2.5.3, current host: 10.24.232.204 #-# org.springframework.jdbc.BadSqlGrammarException:
### Error querying database.  Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'limit 0,50' at line 5
### The error may exist in URL [jar:file:/usr/local/dubbo/xxx/lib/xxx-yyy-1.0.0.jar!/sqlMap/express/XXXXMapper.xml]
### The error may involve xx.yy.zz.XXXXMapper.loadExpress-Inline
### The error occurred while setting parameters
### SQL: select     field as fieldName  from table where field= ?    order by id ASC limit 1 limit ?,?
### Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'limit 0,50' at line 5
; bad SQL grammar []; nested exception is com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'limit 0,50' at line 5

我们来看一下方法实现代码

@Override
public XXXVo loadExpress(param){
    XXXEntity param = new XXXEntity();
    param.setBusinessNo(businessNo);
    XXXEntity  entity = XXXMapper.loadExpress(param);
    //省略无关代码
}

我们看一下sqlmap

<select id="loadExpress" parameterType="xx.yy.zz.XXXEntity"
        resultType="xx.yy.zz.XXXEntity">
    select
        field as fieldName 
    from table 
        where business_no= #{businessNo}
        order by id ASC limit 1
</select>

这个方法是唯一入口，并且没有执行pagehelper.startPage，但是语句在执行的时候自动加了limit 0,50，这个分页的数据非常像是页面的列表查询设置的分页变量。

其实问题所在是执行线程被污染，因为我们都是使用线程池的，当前执行所用的线程是会被放回池子中被反复使用的，如果某个执行污染了线程那就会影响下一个执行的代码。

我们来举个例子，看如下代码：

public void method01() { //@1
    PageHelper.startPage(1, 10); //@5
    List<Country> list;
    if(param1.get() != null){ //@2
        list = countryMapper.selectIf(param1);
    } else {
        list = new ArrayList<Country>();
    }
}
 
public List<Country> method02() { //@3
    List<Country> list = countryMapper.selectNotPage(param1); //@4
    return list;
}

假设我们一个请求进来调用method01()方法，随后另外的请求进来调用的是method02()方法，假定我们的线程池数量是1，让两个请求使用同一个线程。

1. 请求从@1处进入
2. 执行到@2处发生了NullPointException异常
3. 随后的请求从@3处进入
4. 执行@4处时执行的sql会被自动添加limit ?,?。

错误原因

因为前一个请求执行@5处时设置了分页标识到ThreadLocal中，当执行到@2处时触发了异常，@5处设置的分页变量没有被消费和清理，线程被污染，因此另一个请求进来复用了这个线程，当执行到@4处时PageHelper拦截器从ThreadLocal中获取到分页变量并自动增加了limit ?,?语句。

解决方法

推荐使用的方式

在执行PageHelper.startPage(1, 10);之后紧跟着执行Executor，避免这两行之间出现错误，将我们上图举例中的代码修改一下如下：

public void method01() {
    List<Country> list;
    if(param1.get() != null){
        //两行紧挨着执行，避免出现异常
        PageHelper.startPage(1, 10);
        list = countryMapper.selectIf(param1);
    } else {
        list = new ArrayList<Country>();
    }
}

ps. 要保证两行紧挨着执行，并且在执行了PageHelper.startPage之后与countryMapper.selectIf之前保证不会出错误。

不推荐使用方式

使用finally快进行清理，如下图：

public void method01() {
    List<Country> list;
    if(param1.get() != null){
        //修改面太大，代码侵入太多
        try {
            PageHelper.startPage(1, 10);
            list = countryMapper.selectIf(param1);
        } finally {
            PageHelper.clearPage();
        }
    } else {
        list = new ArrayList<Country>();
    }
}

ps. 参考pagehelper的安全使用指南

总结

只有理解了pagehelper的分页机制之后才能别面写法带来的bug，我相信当我提到pagehelper采用ThreadLocal实现的分页标识传递时，应该有很多人已经明白了问题所在。任何通过ThreadLocal传递变量时都有可能出现线程污染的问题，尽量规避掉。

ThreadLocal传递变量是个非常好的方式，俗称为隐士传参，具有包装透明的效果，正因为这个特性更要注意安全清理的问题，需要全面思考代码执行过程中是否会出现错误，出现错误是否能友好的清理掉线程中透传的变量，如果处理不得当就会造成线程污染。

在开发中我们经常会用到对象之间的互相拷贝，Java中对象拷贝的类库也比较多，常见的有Spring BeanUtils，Apache BeanUtils，等并且在很多大厂公司对对象拷贝也有详尽的说明，避免大家踩坑。

功能对比

性能对比

结论

从性能对比来看：

1. cglib的BeanCopier最好， Spring BeanUtils稍微差点，但也还可以，Apache BeanUtils性能最差
2. 从功能对比来看，cglib 在set方法返回非void时，会导致其他属性无法copy，目标没有set方法时，会报错，还存在并且有多项不支持的情况

首先说明：前后端分离并非仅仅只是一种开发模式，而是一种架构模式（前后端分离架构）。

开发模式对比

请求方式对比

前后端分离的优势

前后端分离的劣势

有联调、沟通环节，这个过程非常花时间，也容易出bug，还很难维护。

前后端分离-术业有专攻

后端： 把精力放在 高并发，高可用，高性能，安全，存储，业务等等研究上

例如：设计模式，原理及源码，事务隔离与锁机制，http/tcp，多线程，分布式架构，弹性计算架构，微服务架构，性能优化，以及相关的项目管理等等

前端： 把精力放在页面表现，速度流畅，兼容性，用户体验等等

例如：html5，css3，jquery，angularjs，reactjs，vuejs，webpack，less/sass，gulp，nodejs，Google V8引擎，javascript多线程，模块化，面向切面编程，设计模式，浏览器兼容性，性能优化等等

总结

举个例子

比如说我们要增加代码和任务之间的可追溯性，我们可能考虑采用git+jira关联的方式对开发人员每笔提交在提交comment中增加jira编号，这是就是一个规范，但是规范落地如何检查？开发人员如果忘记在comment中添加就会造成关联失败，那我们就要采用工具的方式帮助开发人员在提交时检查comment是否符合规范。

比如说我们有制定编码规范，也采用了sonar去扫描代码的问题，但是这个方式的缺点是太过滞后，需要质量人员跟进去推动并且效果也不是很好，我们是否可以考虑前置检查点帮助开发人员在代码编写和提交时能主动的发现问题，在代码提交的时候发现规范问题可以直接进行解决再提交，我们可以考虑采用git加checkstyle、pmd、fingbug等工具插件，在代码提交的时候进行规范检测并且进行告警，这样就可以很好的帮助开发人员及时的发现问题，并不是开发已经提交了再去sonar上检查代码规范来发现问题再事后的安排人员去解决，开发人员都有一个习惯，当功能开发好没有问题后他们很少会去主动的修改与重构代码，这样就会导致迟迟不能推进，我们提前了检查点帮助开发人员及时发现问题就可以更好的推行规范的落地。

因此我们要考虑提供一整套代码质量管理的机制，应用在开发全生命周期中，并在关键的流程节点进行验证，从而把控与提升代码的质量。

常见的问题及我的看法

静态代码扫描太滞后，推进吃力

我相信大多都会使用类似sonar这类的静态代码检查工具来检查代码，这里我们不说工具的好坏，我们只说检查问题的修复情况，我相信很多开发都会有一种习惯，在代码写完之后如果上线没有问题的话他们是很少会去主动的优化代码，即使你扫描结果告诉他他也会有各种理由推脱，当然我们可以通过管理的手段强制他们修改，比如说blocker、critical级别的必须全部改掉，其余的看情况修改，当然通过管理手段从上往下会有一定的效果，但是这些都是比较滞后的方式，我们能不能提前发现问题让开发在功能开发过程中就把发现的问题改掉？

这个当然是可以的，我们可以利用代码检查的机制，在代码开发中就让开发去扫描发现问题，在代码提交的时候去校验如果有严重的禁止代码提交。这样一来我们就可以提前来发现并解决问题，这样可能会带来的是开发人员的排斥，开发人员都觉得自己代码写的没有问题，所以这块我们需要把控这个检查规则的宽松度，我们可以结合公司的开发规范，整理不同级别的问题，通过先简后严的方式，先把开发的习惯培养起来后再逐渐的提升严格度，这样一来开发就有个适应期也比较好接受，比如说：我们通过checkstyle的规则模板定义，前期把一些无用导入包、命名不规范、导入包用*、system.out语句这类接受度高的作为error级别来推动开发适应从而培养这种良好的习惯。

团队Code Review没有跑起来或跑的太费事费力

在技术行业做了一定时间的人应该都知道code review是多么的重要，一可以促进团队人员之间互相交流，二可以提升整体团队的技术水平，学习优秀人员写的代码，帮助初级人员提升代码编写能力，所以code review还是强烈必须要做的，至于怎么做code review？我谈一下我的想法和建议

比较常见的方式是定期团队内组织全体人员进行集中式的code review，我比较推荐利用工具在线的操作方式来做code review，现在开源非常的火也可以参考学习开源团队code review的方式，比如说github有pull request，gitlab有merge request，可以在这个合并代码的节点上进行code review，这样做的好处是第一比较开放，只要能看到合并代码请求的都可以进行review，第二可以留下review记录，互相的想法沟通和建议可以很好的留存下来并且可以通过UI的方式友好的展示出来，从而提升code review效率。

这个当然需要结合git flow的机制来协作完成。

代码库分支、版本管理不规范，合并丢代码

团队多了或团队大了，每个人或多或少对git的管理与使用理解不一致，这样就造成了分支、版本管理的混乱，这样在版本代码合并时就会产生很多冲突，我们可以指定一套规范性的东西，指导开发团队进行分支、版本的管理，这里说到的是指导不是限制，要让开发在可控的范围内自由发挥。

可以参考git flow、github flow等，当然我们要统一一个工作流程推广给开发团队中。

前面我们说了用代码合并来进行code review，这样我们就要让开发人员在每开发完一个任务的时候就要进行一次代码合并，git是一个优秀的分布式代码库管理工具，我们利用git的分布式特性，以及灵活的流程机制来规范大家的使用。

例如：

一次迭代冲刺或一个版本对应一个develop-*分支和release-*，并且控制分支的push与merge权限，固定一个master分支并且控制master分支的权限，让个人开发通过feature-{username|功能名称}-*分支来进行功能开发，当一个任务或者一个功能开发完成进行一次develop-*分支的合并，这样一来及可以code review也可以有序的管理分支上的代码，当开发人员提交合并请求时发生了冲突就需要开发人员自己解决完冲突后再进行代码合并请求，这样一来版本分支上代码是有序的。

以上可以定位分支约定。

具体的操作可以参考下面描述：

1. sprint开始时（需求确认后），从master创建develop分支，例如是develop-V1.2.0
2. 开发人员从对应的develop分支创建自己的feature分支进行开发
3. 如果master分支发生变更，需要从master分支合并到对应的develop分支、可以考虑定期合并一次
4. feature分支合并到对应的develop之前，需要从develop分支合并到feature分支（这个避免和其他人提交进行冲突，规范开发人员自己解决掉冲突后才能发起合并请求）
5. feature分支合并到对应的develop之后，发布到测试环境进行测试（测试环境直接使用对应的develop分支）
6. develop分支在测试环境测试通过之后，合并到对应的release分支并发布到预发布环境（UAT）进行测试
7. release分支在预发布环境（UAT）验证通过后，合并到master分支并发布到生产环境进行验证
8. 发布到生产环境后从master分支构建对应的版本tag

可同时支持多个sprint的并行。

代码提交备注写的很难懂甚至很随意

代码的提交备注非常重要，尤其是在合并代码时产生冲突，第一时间肯定是根据提交日期去看本次提交做了什么修改，如果说备注随便填写，或者有些都没有填这样在回头来看的时候，及时是提交本人他也不能第一时间看出具体做了哪些修改，因此我觉得作为一个开发人员提交备注写的清晰明了是一件必备的职业素养，至于一些不按照规范的技术人员我们也可以要求他们按照规范必须填写。

那如何做到对备注填写的质量把控呢？我们可以通过版本管理工具在提交代码时进行提交备注检测，比如说对长度的限制，至少要15个字符，或者对格式做一些验证，必须包含任务编号之类，这样一来就可以有效的控制代码提交备注的质量以及可读性。

我们现在常用的git就有hook机制可以提供在代码提交前后做一些钩子，利用钩子来控制允许提交或者拒绝提交，比如说git的pre-commit和commit-msg

开发人员的任务管理与提交代码没有关联，无法查看某个任务具体提交了哪些代码

优秀的开发人员主动性都是很好的，主动性对开发来说也是非常重要的职业素养，不要让人催促你来完成任务，自己要学会主动找任务去做主动想如何优化与提升，所以时间任务管理是非常重要的，我任务开发人员都应该具备自己的时间任务管理能力，无论用什么工具只要能管理跟踪好自己的任务就是不错的人员。

公司一般都有任务管理工具，有的用禅道、有的用jira，现在用jira的相对多一些，jira的功能丰富也可以促进团队进行敏捷的任务管理，我们可以通过打通任务管理工具和代码版本工具，让代码提交的时候通过任务编号产生关联，从而可以在任务中看到代码修改的片段。

这里我用jira+git举个例子，比如说我们利用jira做scrum的敏捷管理，在制定好epic、story、task、subtask后，可以通过scrum模型的管理手段，在开发过程中通过插件、图标的数据来分析是否有风险？那个人的任务delay？那个人的任务制定还可以再进行拆分？等，从而尽早的做出调整来控制整个迭代周期按时完成。利用git提交的备注写入jira编号，通过jira和git的插件打通任务与提交代码的关联，这样一来我们就可以很好的看到任务执行过程数据与具体改动了哪些代码，从而提升开发效率。

统一管理校验规则版本，由简到严循序渐进的方式提升代码质量

我们上面说到的利用了checkstyle来验证代码风格，通过git hook来控制提交备注的规范，这些都需要自定义一些脚本，这些脚本也应该利用git进行有效的管理，我们能力能做到统一的调整了规则与脚本，开发过程中的应用立即使用最新的验证规则？还有git hooks的脚本是在开发机器本地运行的，这样就带来了一个问题如何让开发去安装脚本呢？叫他们手动安装？写个bat或shell脚本让开发执行一次？

我觉得更好的方式是对开发透明在他们不知觉的时候已经悄悄的安装，我们可以利用git对规则与脚本的版本进行管理，利用nginx可以通过http方式直接访问规则与脚本文件，通过自定义maven plugin在代码build的时候验证开发机器上是否已经安装，如果没有就给它自动安装与自动更新。

这样我们只要修改了规则与脚本后进行版本发布，开发机就会自动的更新下来从而可以立即生效。

开发团队技术氛围低沉

很多公司开发团队一味的满头苦干，很容易忽视团队内的技术分享，再加上团队内人员进进出出有一些正能量的人当然也有一些负能量的人，这都是常事，但是不管怎样我相信做技术的人都愿意提升自己的技术能力，不管是工作中实践学习还是说参加沙龙或者论坛，都是很好的学习渠道，人的精力也是比较有限不可能关注很多面，通过团队内的技术分享，把每个人擅长的部分分享给大家，互相学习来提升凝聚力和团队整体的技术水平，这样长期以来我相信团队内的技术氛围肯定不会差。

总结

以上就是我对代码质量管理与提升方面的经验与思考，里面涉及到很多东西，有流程的制定、工具的协作、工具的打通、规范的制定等，因此这是一个系统性的方案，希望可以利用一整套代码质量管理的流程，在关键的流程节点来把控代码的质量，形成闭环，希望可以帮助有需要的人，如果有更好的建议也希望大家多提意见进行补充，没有完美的方式，只有找到适合的可落地的就是好的。

问题描述

1. 两个事物， 在第一个事务报错是则执行第二个事务
2. 两个事物都是执行下面的批量操作
3. 两个事务的批量操作是插入到相同的两张表中，如下代码
4. 第一个事务预计在第一个表中插入3条记录， 第二个表中插入3条记录，但是第一个表的第一个记录就违反了约束，报错异常；
5. 第一个事务失败后，执行第二个事务，第二个事务插入两个表中各一条记录。
6. 实际结果：第一个表有一条记录（第二个事务中插入的），第二个表中有4条记录（除了第二个事务中的一条，还有第一个事务中的3条数据）

问题点是在第一个事务抛异常回滚了，第一个表成功回滚，但是第二个事务将第一个事务中的第二个表的数据提交了。

问题原因

1. 我们说明批量操作是指：如下的样例:insert into t(field) values(v1),(v2),(v3)
2. sqlSession.commit();实际上并不是事务的commit，而只是执行sql
3. 2个事务绑定的是同一个connection。
4. 在一个mybatis的sqlSession 批量中操作两张表，则会生成两个prepareStatement，
5. 而prepareStatement对象在mybatis中有cache。
6. 回滚时回滚到savepoint

基于上面6点， 当第一个事务的第一个表执行是失败后（在第一个表的失败位置上设置一个savepoint，回滚时值回滚到这个savepoint，第二个preparestatement被缓存了）

问题总结

1. 本问题不设计到事务传播机制与隔离级别
2. 本例为一个错误使用范例，即不能在一个mybatis的sqlSession批量中操作两张表

注意：PreparedStatement确实适合执行相同sql的批处理，Statement适合执行不同sql的批处理

一些代码跟踪截图这里就不方便放出来请见谅。

下面我们就细说一下日期类型的参数将如何处理。

GET方法时参数传入日期类型该如何处理

举例

url如下：

http://localhost:8081/test/time_get?time=2018-07-09 10:38:57

Controller代码：

import java.util.Date;

@RequestMapping(value = "/time_get", method = RequestMethod.GET)
@ResponseBody
public Response<Date> time_get(Date time) {
    logger.info("time:{}", time);
    return Response.createResponse(time);
}

在这种情况下日期参数是无法成功的传入到controller方法里，会爆出如下的异常：

org.springframework.core.convert.ConversionFailedException: Failed to convert from type java.lang.String to type java.util.Date for value '2018-07-09 10:38:57'; nested exception is java.lang.IllegalArgumentException
at org.springframework.core.convert.support.ObjectToObjectConverter.convert(ObjectToObjectConverter.java:81) ~[spring-core-4.0.0.RELEASE.jar:4.0.0.RELEASE]
 at org.springframework.core.convert.support.ConversionUtils.invokeConverter(ConversionUtils.java:35) ~[spring-core-4.0.0.RELEASE.jar:4.0.0.RELEASE]
 at org.springframework.core.convert.support.GenericConversionService.convert(GenericConversionService.java:178) ~[spring-core-4.0.0.RELEASE.jar:4.0.0.RELEASE]
 at org.springframework.beans.TypeConverterDelegate.convertIfNecessary(TypeConverterDelegate.java:161) ~[spring-beans-4.0.0.RELEASE.jar:4.0.0.RELEASE]
 at org.springframework.beans.TypeConverterDelegate.convertIfNecessary(TypeConverterDelegate.java:93) ~[spring-beans-4.0.0.RELEASE.jar:4.0.0.RELEASE]
 at org.springframework.beans.TypeConverterSupport.doConvert(TypeConverterSupport.java:64) ~[spring-beans-4.0.0.RELEASE.jar:4.0.0.RELEASE]
 ... 43 common frames omitted
Caused by: java.lang.IllegalArgumentException: null
 at java.util.Date.parse(Date.java:615) ~[na:1.7.0_45]
 at java.util.Date.<init>(Date.java:272) ~[na:1.7.0_45]
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.7.0_45]
 at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) ~[na:1.7.0_45]
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[na:1.7.0_45]
 at java.lang.reflect.Constructor.newInstance(Constructor.java:526) ~[na:1.7.0_45]
 at org.springframework.core.convert.support.ObjectToObjectConverter.convert(ObjectToObjectConverter.java:76) ~[spring-core-4.0.0.RELEASE.jar:4.0.0.RELEASE]
 ... 48 common frames omitted

那如何解决上面的问题？使用@DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss")加到日期参数之前，像下面那样使用一样。

Controller代码：

import java.util.Date;
 
@RequestMapping(value = "/time_get", method = RequestMethod.GET)
@ResponseBody
public Response<Date> time_get(@DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss") Date time) {
    logger.info("time:{}", time);
    return Response.createResponse(time);
}

提示：年月日：pattern=”yyyy-MM-dd”，年月日时分秒：pattern=”yyyy-MM-dd HH:mm:ss”

请求体：

GET /test/time_get1?time=2018-07-09 11:31:00 HTTP/1.1
Host: localhost:8081

后端接收到的信息，debug截图：

POST方法时参数传入日期类型该如何处理

当使用@RequestBody接受一个VO对象时@DateTimeFormat就会失效，因为我们走的是Json序列化与反序列化，@DateTimeFormat只会生效与object序列化、反序列化。如果使用的Spring可以自定义messageConvert或者增强MappingJackson2HttpMessageConverter中的ObjectMapper

代码如下：

import java.text.SimpleDateFormat;
import java.util.ArrayList;
import java.util.List;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.http.converter.HttpMessageConverter;
import org.springframework.http.converter.json.MappingJackson2HttpMessageConverter;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurationSupport;
import org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping;

import com.fasterxml.jackson.databind.DeserializationFeature;
import com.fasterxml.jackson.databind.ObjectMapper;

@Configuration
public class WebConfig extends WebMvcConfigurationSupport {
    @Override
    protected void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
        List<HttpMessageConverter<?>> messageConverters = new ArrayList<HttpMessageConverter<?>>();
        addDefaultHttpMessageConverters(messageConverters);
        for (int i = 0; i < messageConverters.size(); i++) {
            HttpMessageConverter<?> mc = messageConverters.get(i);
            if (mc instanceof MappingJackson2HttpMessageConverter) {
                ObjectMapper objectMapper = new ObjectMapper();
                //当json中属性在反序列化时，javabean中没有找到属性就忽略，如果FAIL_ON_UNKNOWN_PROPERTIES=true找不到属性会报错
                objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
                //设置序列化、反序列化时日期类型的格式
                objectMapper.setDateFormat(new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));
                ((MappingJackson2HttpMessageConverter) mc).setObjectMapper(objectMapper);
            }
            converters.add(mc);
        }
    }
}

注意：使用Jackson进行json序列化反序列化，默认可以处理yyyy-MM-dd这个格式，但是反序列化后的时间会差8小时

通过上面对json序列化反序列化的配置后日期参数处理就变的简单了，效果如下。

Controller代码：

@RequestMapping(value = "/time_post", method = RequestMethod.POST)
@ResponseBody
public Response<Date> time_post(@RequestBody TestVo vo) {
    logger.info("time:{}", vo.getTime());
    return Response.createResponse(vo.getTime());
}

VO代码：

public class TestVo implements Serializable {
    private static final long serialVersionUID = 7435595656552442126L;
    private Date time;
    public Date getTime() {
        return time;
    }
    public void setTime(Date time) {
        this.time = time;
    }
}

提示：VO中无需使用@DateTimeFormat，就是一个普通的javabean即可

请求体：

POST /test/time_post HTTP/1.1
Host: localhost:8081
Content-Type: application/json
{
    "time":"2018-07-09 15:31:00"
}

后端接收到的信息，debug截图

PUT方法时参数传入日期类型该如何处理

如果put传参方式与get一样在方法上直接传参（url?time=2018-07-09 10:38:57），那参考get请求参数处理方式即可

如果put传参方式与post一样使用@RequestBody传入json格式数据，那么参考post请求参数处理方式即可

请求体：

PUT /test/time_put HTTP/1.1
Host: localhost:8081
Content-Type: application/json
{
    "time":"2018-07-09 15:31:00"
}

后端接收到的信息，debug截图

前面都说的是request时日期格式处理方式，那么我们继续说一下response时日期格式如何处理。

Response中日期格式该如何处理

SpringMVC使用@ResponseBody时，日期格式默认显示为时间戳，不管方法直接返回Date类型、或者VO类型时，时间格式都一样返回时间戳，例如这样。

请求体：

POST /test/time_post1 HTTP/1.1
Host: localhost:8081
Content-Type: application/json
{
    "time":"2018-07-09"
}

响应体：

{
    "code": "",
    "message": "",
    "items": {
        "time": 1531094400000
    }
}

那如果我们要以字符串格式返回呢，那该如何处理？

方法一增加统一的messageConvert处理：

如果使用的spring可以自定义messageConvert或者增强MappingJackson2HttpMessageConverter中的ObjectMapper

代码在POST方法时参数传入日期类型该如何处理这个章节

方法二通过@JsonFormat注解处理：

请在VO对象的date字段上加上@JsonFormat(pattern="yyyy-MM-dd HH:mm:ss",timezone = "GMT+8"),例如下面代码：

VO代码：

public class TestVo implements Serializable {
    private static final long serialVersionUID = 7435595656552442126L;
 
    @JsonFormat(pattern="yyyy-MM-dd HH:mm:ss",timezone = "GMT+8")
    private Date time;
    public Date getTime() {
        return time;
    }
    public void setTime(Date time) {
        this.time = time;
    }
}

注意：@JsonFormat(pattern=”yyyy-MM-dd HH:mm:ss”,timezone = “GMT+8”) ，即可将json返回的对象为指定的类型。

返回日期格式使用的是”yyyy-MM-dd HH:mm:ss”样式字符串示例：

请求体：

POST /test/time_post1 HTTP/1.1
Host: localhost:8081
Content-Type: application/json
{
    "time":"2018-07-09 15:31:00"
}

响应体：

{
    "code": "",
    "message": "",
    "items": {
        "time": "2018-07-09 15:31:00"
    }
}

日期格式处理规范

这里有的人喜欢使用时间戳，有的人喜欢使用统一格式化的时间字符串yyyy-MM-dd HH:mm:ss，我个人的建议使用后者，因为这样比较直观调试交流起来也比较方便。

使用哪种没有对错，其实就是一种规范，统一规范可以提升协作效率，因此我建议的规范如下：

• 前端传入日期格式：yyyy-MM-dd HH:mm:ss，例如：2018-07-09 12:55:12（不使用时间戳，前后双方联调时查看起来更加友好）
• 后端返回日期格式：yyyy-MM-dd HH:mm:ss，例如：2018-07-09 12:55:12（不使用时间戳，前后双方联调时查看起来更加友好）
• 后端json序列化、反序列化框架：定义任何一种高效的json工具都行，例如：Fastjson、Gson、Jackson lib
• 序列化、反序列化日期格式规范：pattern=”yyyy-MM-dd HH:mm:ss”,timezone = “GMT+8”，除特出场景可以使用pattern=”yyyy-MM-dd”,timezone = “GMT+8”
• 不要随意自定义convert处理日期格式以及其他特殊格式转换，应该交由基础框架组或架构组统一在框架层面解决，对业务开发透明，或者在有些小公司由Leader或高开来担当。

这些都是我个人摸爬滚打多年码出来的心得体会，说的不好还请见谅，希望可以帮助有需要的人。

提供自定义也是一个系统扩展性的体现，自定义功能的强大自然能适应更多的用户场景。

接下来我们就看看自定义的实现方案通常都有哪些方式。

常见的自定义字段的实现方式分为三种由简到繁，扩展性、复杂性也是逐渐增强的，每个方式各有优劣解决的场景也有所不同，具体往下看。

列式存储自定义字段（扩展字段 ext field）

模型如下：

优点：

1. 实现成本最低
2. 可以直接表连接进行检索

缺点：

1. 扩展能力一般，有上限
2. 浪费资源，比如说有20个扩展字段，一行只用到2个，其余的18个都要存储null来浪费空间。
3. 能解决的场景比较有限。

EAV模型 Entity-Attribute-Value（实体、属性、值）

对象属性存储在一个有三列的表中：实体，属性和值（entity，attribute，value)。实体（entiry）表示所描述的数据项，例如一个产品或汽车。属性（attribute）表示描述实体的数据，例如一个产品将有价格，重量和许多其他属性。值（value）是属性的值，例如产品可能有一个9.99英镑的价格属性。此外值可以基于数据类型进行分割，所以可将EAV表分为字符串、整数、日期和长文本（long text）表。依据数据类型分割是为了支持索引,使得数据库执行可能的类型检查验证。

EAV表模型带来了数据的灵活性，是的增加对象的属性不需要用增加数据库的字段，有很高的灵活性。但是EAV表也有较大的性能问题。通常，EAV表带来的一个问题是当查找多个字段时，需要进行关联查询join,这样的查询效率比较低。为了提高查询效率，我们可以对商品属性表进行矩阵转积处理(pivoting)。

一种方式是在代码中读出后存入cache中,当修改attributes表后触发更新cache或用cron定期更新;另一种方法是将关联信息组成一张大的临时表，数据的更新可以用数据库的触发器触发更新。由于大量数据在代码中进行处理会带来了DB的额外IO和服务器性能问题。当使用EAV表模型时，InnoDB比MYISAM的性能要好不少。

ps. 我们常用的行模型（纵向）存储就是EAV模型实现的一种方式。

模型如下：

人员表（Entity）

扩展映射（Entities）

优点：

1. 扩展能力较强
2. 理论上无上限
3. 可以支持几乎所有的自定义字段的需求

缺点：

1. 关联查询效率低下
2. 需要维护自定义字段与值的关系表

Json格式存储自定义字段

json格式非常丰富，在描述自定义字段的这方面比较适合，可以把一行多列的数据压缩到一个json text内，也比较节省空间，json格式可以无限扩展，还可支持多个自定义字段有不同的格式。

模型如下：

ps. 支持以上的两种不同的自定义格式并存

优点：

1. 扩展能力强
2. 理论上无上限
3. 可以支持几乎所有的自定义字段的需求
4. 无需维护自定义字段与值关系

缺点：

1. 数据库需要支持json type，不建议使用text类型
2. 不支持关联查询（mongodb除外）
3. 自定义字段检索需要通过其他方式，例如搜索引擎。（mongodb除外）

数据库对Json格式支持情况

数据库对Json类型的支持：

1. Mysq5.7（CRUD参考）
2. PostgreSQL（CRUD参考，json与jsonb区别）
3. MongoDB（CRUD参考）

数据库对json类型的检索支持：

1. Mysql5.7： 支持索引：通过虚拟列的功能可以对JSON中部分的数据进行索引。（相比PG和MongoDB弱一些，通过json_extract()函数做一些简单查询）
2. PostgreSQL：支持检索，可以复杂查询
3. MongoDB：支持检索，可以复杂查询，支持map reduce

ORM框架对Json类型的支持：

1. Mybatis支持json格式字段映射到POJO，方便json格式的bean与数据库映射。
2. Hibernate支持json格式字段映射到POJO，方便json格式的bean与数据库映射。

Mysql5.7.x json操作官方文档：

1. json-creation-functions
2. json-search-functions
3. json-modification-functions

Mysql5.7.x 注意事项：

1. JSON_UNQUOTE 、->、->> 之间的区别
   • 下面三个表达式返回相同的值
     • JSON_UNQUOTE( JSON_EXTRACT(column, path) )
     • JSON_UNQUOTE(column -> path)
     • column->>path
2. JSON_CONTAINS_PATH 参数说明
   • 第二个参数为’one’或’all’的区别
     • ‘one’：至少存在一个路径返回1，反之返回0
     • ‘all’：全部路径存在返回1，反之返回0
3. JSON_CONTAINS 参数说明
   • 第二个参数是不接受整数的，无论 json 元素是整型还是字符串，否则会出现这个错误
4. 5.7.x不同版本支持的程度：
   • MySQL 5.7.13
     • 支持操作符 ->>
   • MySQL 5.7.9
     • 支持操作符 -> （JSON_EXTRACT()函数别名）
     • 重命名函数JSON_APPEND()为JSON_ARRAY_APPEND()，函数作用：将值追加到JSON文档中指定数组的末尾并返回结果，未来会删除’JSON_APPEND()’
   • MySQL 5.7.22
     • 支持JSON_ARRAYAGG()返回json数组形式结果集，JSON_OBJECTAGG()返回kson对象形式结果集
     • 添加JSON_MERGE_PATCH()，作用：合并结果（相同path）
     • 添加JSON_MERGE_PRESERVE()，作用：合并数据（不同path）
     • 弃用JSON_MERGE()，使用JSON_MERGE_PRESERVE() / JSON_MERGE_PATCH()，未来会删除’JSON_MERGE()’

实现方式不局限于上面说到的方式，有更好的方式欢迎留言进行沟通。

我擦好牛逼了，自1996年起的计算机科学最佳论文奖全收录，不说了戳开看吧。

github: jmeter-plugin-dubbo

码云: jmeter-plugin-dubbo

V1.3.8

What is new:

1. Enumeration type support. #34
2. Support group to zookeeper,redis registration center. #33

新版改进：

1. 支持枚举类型参数。#34
2. zookeeper、redis作为注册中心时增加group支持。 #33

ps. 参数类型支持：枚举类型以及参数对象内属性为枚举类型

截图

ps. dubbo:registry group: 服务注册分组，跨组的服务不会相互影响，也无法相互调用，适用于环境隔离。

具体查看dubbo文档

先来科普一下SnowFlake算法

算法原理

Twitter Snowflake 生成的 unique ID 的组成 (由高位到低位):

41 bits: Timestamp (毫秒级)
10 bits: 节点 ID (datacenter ID 5 bits + worker ID 5 bits)
12 bits: sequence number
一共 63 bits (最高位是 0).

| 0(最高位预留) | 时间戳(41位) | 机器ID(10位) | 自增序列(12位) |

unique ID 生成过程:

• 10 bits 的机器号, 在 ID 分配 Worker 启动的时候，从一个 Zookeeper 集群获取 (保证所有的 Worker 不会有重复的机器号)；
• 41 bits 的 Timestamp: 每次要生成一个新 ID 的时候，都会获取一下当前的 Timestamp, 然后分两种情况生成 sequence number；
• 如果当前的 Timestamp 和前一个已生成 ID 的 Timestamp 相同 (在同一毫秒中)，就用前一个 ID 的 sequence number + 1 作为新的 sequence number (12 bits);
  如果本毫秒内的所有 ID 用完，等到下一毫秒继续 (这个等待过程中, 不能分配出新的 ID)；
• 如果当前的 Timestamp 比前一个 ID 的 Timestamp 大, 随机生成一个初始 sequence number (12bits) 作为本毫秒内的第一个 sequence number；

41-bit的时间可以表示（1L<<41）/(1000L x 3600 x 24 x 365)=69年的时间，10-bit机器可以分别表示1024台机器。如果我们对IDC划分有需求，还可以将10-bit分5-bit给IDC，分5-bit给工作机器。这样就可以表示32个IDC，每个IDC下可以有32台机器，可以根据自身需求定义。12个自增序列号可以表示2^12个ID，理论上snowflake方案的QPS约为409.6w/s，这种分配方式可以保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不同的。

优缺点这里就不赘述了。

那我们继续看一个经典的Java版本的实现，这个在网上一搜一大把，官方原版的Scala版本

public class Snowflake {

private static final Logger logger = LoggerFactory.getLogger(Snowflake.class);

/**
 * 机器ID
 */
private final long workerId;
/**
 * 时间起始标记点，作为基准，一般取系统的最近时间，默认2017-01-01
 */
private final long epoch = 1483200000000L;
/**
 * 机器id所占的位数（源设计为5位，这里取消dataCenterId，采用10位，既1024台）
 */
private final long workerIdBits = 10L;
/**
 * 机器ID最大值: 1023 (从0开始)
 */
private final long maxWorkerId = -1L ^ -1L << this.workerIdBits;
/**
 * 机器ID向左移12位
 */
private final long workerIdShift = this.sequenceBits;
/** 
 * 时间戳向左移22位(5+5+12)
 */
private final long timestampLeftShift = this.sequenceBits + this.workerIdBits;
/** 
 * 序列在id中占的位数
 */
private final long sequenceBits = 12L;
/** 
 * 生成序列的掩码，这里为4095 (0b111111111111=0xfff=4095)，12位
 */
private final long sequenceMask = -1L ^ -1L << this.sequenceBits;
/**
 * 并发控制，毫秒内序列(0~4095)
 */
private long sequence = 0L;
/** 
 * 上次生成ID的时间戳 
 */
private long lastTimestamp = -1L;

private final int HUNDRED_K = 100_000;

/**
 * @param workerId 机器Id
 */
private Snowflake(long workerId) {
if (workerId > this.maxWorkerId || workerId < 0) {
String message = String.format("worker Id can't be greater than %d or less than 0", this.maxWorkerId);
throw new IllegalArgumentException(message);
}
this.workerId = workerId;
}

/**
 * Snowflake Builder
 * @param workerId workerId
 * @return Snowflake Instance
 */
public static Snowflake create(long workerId) {
return new Snowflake(workerId);
}

/**
 * 批量获取ID
 * @param size 获取大小，最多10万个
 * @return SnowflakeId
 */
public long[] nextId(int size) {
if (size <= 0 || size > HUNDRED_K) {
String message = String.format("Size can't be greater than %d or less than 0", HUNDRED_K);
throw new IllegalArgumentException(message);
}
long[] ids = new long[size];
for (int i = 0; i < size; i++) {
ids[i] = nextId();
}
return ids;
}

/**
 * 获得ID
 * @return SnowflakeId
 */
public synchronized long nextId() {
long timestamp = timeGen();

// 如果上一个timestamp与新产生的相等，则sequence加一(0-4095循环);
if (this.lastTimestamp == timestamp) {
// 对新的timestamp，sequence从0开始
this.sequence = this.sequence + 1 & this.sequenceMask;
// 毫秒内序列溢出
if (this.sequence == 0) {
// 阻塞到下一个毫秒,获得新的时间戳
timestamp = this.tilNextMillis(this.lastTimestamp);
}
} else {
// 时间戳改变，毫秒内序列重置
this.sequence = 0;
}

// 如果当前时间小于上一次ID生成的时间戳，说明系统时钟回退过这个时候应当抛出异常
if (timestamp < this.lastTimestamp) {
String message = String.format("Clock moved backwards. Refusing to generate id for %d milliseconds.", (this.lastTimestamp - timestamp));
logger.error(message);
throw new RuntimeException(message);
}

this.lastTimestamp = timestamp;
// 移位并通过或运算拼到一起组成64位的ID
return timestamp - this.epoch << this.timestampLeftShift | this.workerId << this.workerIdShift | this.sequence;
}

/**
 * 等待下一个毫秒的到来, 保证返回的毫秒数在参数lastTimestamp之后
 * @param lastTimestamp 上次生成ID的时间戳 
 * @return
 */
private long tilNextMillis(long lastTimestamp) {
long timestamp = timeGen();
while (timestamp <= lastTimestamp) {
timestamp = timeGen();
}
return timestamp;
}

/**
 * 获得系统当前毫秒数
 */
private long timeGen() {
return System.currentTimeMillis();
}

}

那让我们看一下代码来理解一下算法的细节。

代码理解

我们从关键的代码段来理解，如下：

this.sequence = this.sequence + 1 & this.sequenceMask;

private final long maxWorkerId = -1L ^ -1L << this.workerIdBits;

return ((timestamp - this.epoch) << this.timestampLeftShift)
 | (this.workerId << this.workerIdShift)
 | this.sequence;

ps. 我这里取消了datacenterId，将datacenterId和workerid合并到workerIdBits

负数的二进制表示

在计算机中，负数的二进制是用补码来表示的。
假设我是用Java中的int类型来存储数字的，
int类型的大小是32个二进制位（bit），即4个字节（byte）。（1 byte = 8 bit）
那么十进制数字3在二进制中的表示应该是这样的：

00000000 00000000 00000000 00000011
// 3的二进制表示，就是原码

那数字-3在二进制中应该如何表示？
我们可以反过来想想，因为-3+3=0，
在二进制运算中把-3的二进制看成未知数x来求解，
求解算式的二进制表示如下：

   00000000 00000000 00000000 00000011 //3，原码
+  xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx //-3，补码
-----------------------------------------------
   00000000 00000000 00000000 00000000

反推x的值，3的二进制加上什么值才使结果变成00000000 00000000 00000000 00000000？：

   00000000 00000000 00000000 00000011 //3，原码                         
+  11111111 11111111 11111111 11111101 //-3，补码
-----------------------------------------------
 1 00000000 00000000 00000000 00000000

反推的思路是3的二进制数从最低位开始逐位加1，使溢出的1不断向高位溢出，直到溢出到第33位。然后由于int类型最多只能保存32个二进制位，所以最高位的1溢出了，剩下的32位就成了（十进制的）0。

补码的意义就是可以拿补码和原码（3的二进制）相加，最终加出一个“溢出的0”

以上是理解的过程，实际中记住公式就很容易算出来：

补码 = 反码 + 1
补码 = （原码 - 1）再取反码
因此-1的二进制应该这样算：

00000000 00000000 00000000 00000001 //原码：1的二进制
11111111 11111111 11111111 11111110 //取反码：1的二进制的反码
11111111 11111111 11111111 11111111 //加1：-1的二进制表示（补码）

具体对位运算以及二进制的计算理解可以看看这篇文章https://blog.csdn.net/cj2580/article/details/80980459

github: jmeter-plugin-dubbo

码云: jmeter-plugin-dubbo

V1.3.7

What is new:

1. Support to select provider from zookeeper. issue: #31
2. Upgrade dubbo version to v2.6.4.

新版改进：

1. 支持从zookeeper选择服务提供者，降低手动输入出错概率，issue: #31
2. 升级dubbo版本到v2.6.4

截图

问题描述

测试程序时发现queue的consumer数量配置与预期不一致，具体如何不一致看下面的测试。

现象一

当我们使用下面配置，listener使用同一个task-executor并且监听三个queue时，consumer使用20-20，只会有一个queue能达到20个consumer，其余两个queue的consumer=0

<bean id="queueMessageExecutor1" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
   <property name="corePoolSize" value="20" />
   <property name="maxPoolSize" value="20" />
   <property name="daemon" value="true" />
   <property name="keepAliveSeconds" value="120" />
</bean>
<jms:listener-container task-executor="queueMessageExecutor1" destination-type="queue" container-type="default" connection-factory="pooledConnectionFactory"
                  concurrency="20-20" acknowledge="auto" receive-timeout="60000">
   <jms:listener destination="QUEUE.EMAIL" ref="mailMessageListener" />
   <jms:listener destination="QUEUE.SMS" ref="smsMessageListener" />
   <jms:listener destination="QUEUE.WECHAT" ref="wechatMessageListener" />
</jms:listener-container>

效果如下图：

现象二

当我们去掉listener-container的receive-timeout="60000"的配置，三个queue的consumer都等于20。

<bean id="queueMessageExecutor1" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
   <property name="corePoolSize" value="20" />
   <property name="maxPoolSize" value="20" />
   <property name="daemon" value="true" />
   <property name="keepAliveSeconds" value="120" />
</bean>
<jms:listener-container task-executor="queueMessageExecutor1" destination-type="queue" container-type="default" connection-factory="pooledConnectionFactory"
                  concurrency="20-20" acknowledge="auto">
   <jms:listener destination="QUEUE.EMAIL" ref="mailMessageListener" />
   <jms:listener destination="QUEUE.SMS" ref="smsMessageListener" />
   <jms:listener destination="QUEUE.WECHAT" ref="wechatMessageListener" />
</jms:listener-container>

效果如下图：

这两种现象之间的差异就在receive-timeout="60000"这个属性上，接下来让我们看一下“现象一”、“现象二”的jvm启动的consumer线程的具体信息，如下图：

现象一的线程信息：

现象二的线程信息：

从线程的信息上看，线程的数量与线程池的配置信息吻合，具体开多少个线程取决于线程池的大小，这个与预期一致，拿为什么两种现象锁显示的queue的consumer数量不同呢？

同样是20个线程，但是在现象二中三个queue的consumer分别都是20个，那总数就是60个完全超过了线程的数量，从这点能看的出来consumer的数量是逻辑数量，也就是说20个线程来承接60个逻辑消费者，每个线程会随机的去拿某一个queue里的消息。

测试消费者

当我们在“现象一”中只有一个queue有consumer，其他queue没有consumer，我们往没有consumer的q中写消息，看些消息的这个q是否有会consumer出现？

当消息积压到一定的时间（测试下来时间为：14:18分积压消息，14:27分增加了20个consumer消费掉了积压消息）

我们再往wechat中发送积压消息，看看wechat的consumer是否会增加？

当消息积压到一定的时间（测试下来时间为：14:34分积压消息，14:38分增加了20个consumer消费掉了积压消息）

一旦增加上来了consumer目前看下来不会自动消失

测试后结论

当listener-container使用同一个task-executor并且监听多个q时：

• listener-container设置了receive-timeout="60000（接受超时时间），线程数会优先处理配置中第一个q上，其他q不会有consumer数量，当其他q有消息积压时会自动增加consumer数量，但是增加的时间不太规律。
• listener-container没有设置receive-timeout="60000（接受超时时间），线程数会处理多个q的消息接收，随机接收某个q的消息，或者是那个q的消息积压的多会优先接受那个q的消息。

ps. 同一个listener-container监听多个q，线程会接收多个q的消息（多个q共享接收消息线程），只不过q的consumer数量初始化的时间不同，如果不配置receive-timeout="60000（接受超时时间）这个参数，q的consumer数量在启动时就会初始化。

当listener-container使用不同的task-executor并且只监听一个q时：

• 设不设置receive-timeout="60000（接受超时时间）没有区别，一个线程池中的线程只会处理一个q的消息接收，对于消息量大存在积压的情况下，可以独立配置线程池和监听器让这个q的处理线程资源独享。

问题描述

最近运维在部署应用的时候偶尔会碰到下面的异常：

Exception in thread "main" java.lang.NoClassDefFoundError: org.springframework.beans.FatalBeanException
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:547)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:475)
    at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:304)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:228)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:300)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:195)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:700)
    at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:760)
    at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482)
    at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139)
    at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:93)
    at com.alibaba.dubbo.container.spring.SpringContainer.start(SpringContainer.java:50)
    at com.alibaba.dubbo.container.Main.main(Main.java:80)

这个异常看上去是org.springframework.beans.FatalBeanException在运行时找不到class，但是调试起来很懵逼。

问题分析

尝试一

怀疑这个类org.springframework.beans.FatalBeanException在classloader的时候无法找到。

这个类org.springframework.beans.FatalBeanException在spring-beans包下，查看打包的lib下存在spring-beans包，查看运行jar中的META-INF下的MANIFEST.MF文件中也有lib/spring-beans-4.0.0.RELEASE.jar

因此排除了这个怀疑。

ps.这里要区分一下NoClassDefFoundError和ClassNotFoundException异常看这篇文章

尝试二

这个类在spring-beans包中，那是不是这个jar包损坏无法读取？

查看了jar包信息以及打开与解压也排除了jar包损坏的可能性。

尝试三

修改log级别改为debug看会不会有更多的日志输出。

通过日志级别的调整为debug后，除了都了一些debug的常规日志以外，错误相关的日志还是跟上面的输出一样，因此也是无济于事。

尝试四

通过arthas观察org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory这个类的doCreateBean这个方法异常的输出。

arthas ${pid}
 
watch org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory doCreateBean "{params, throwExp}" -e -x 2

发现如下更多的日志：

ts=2018-09-25 18:06:37;result=@ArrayList[
    @Object[][
        @String[xxxMapper],
        @RootBeanDefinition[Root bean: class [org.mybatis.spring.mapper.MapperFa
ctoryBean]; scope=singleton; abstract=false; lazyInit=false; autowireMode=2; dep
endencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; fac
toryMethodName=null; initMethodName=null; destroyMethodName=null; defined in URL
 [jar:file:/E:/user/desktop/ningyu/Desktop/xxx-main-1.0.0-SNAPSHOT-201809251509/
lib/xxx-service-JD-1.0.0-SNAPSHOT.jar!/com/xxx/xxx/order/mapper/xxxMapper.class]],
        null,
    ],
    java.lang.NoClassDefFoundError: org.springframework.beans.FatalBeanException
        at org.springframework.beans.factory.support.AbstractAutowireCapableBean
Factory.doCreateBean(AbstractAutowireCapableBeanFactory.java:547)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBean
Factory.createBean(AbstractAutowireCapableBeanFactory.java:475)
        at org.springframework.beans.factory.support.AbstractBeanFactory$1.getOb
ject(AbstractBeanFactory.java:304)
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistr
y.getSingleton(DefaultSingletonBeanRegistry.java:228)
        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBe
an(AbstractBeanFactory.java:300)
        at org.springframework.beans.factory.support.AbstractBeanFactory.getType
ForFactoryBean(AbstractBeanFactory.java:1420)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBean
Factory.getTypeForFactoryBean(AbstractAutowireCapableBeanFactory.java:788)
        at org.springframework.beans.factory.support.AbstractBeanFactory.isTypeM
atch(AbstractBeanFactory.java:543)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.
doGetBeanNamesForType(DefaultListableBeanFactory.java:384)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.
getBeanNamesForType(DefaultListableBeanFactory.java:361)
        at org.springframework.beans.factory.BeanFactoryUtils.beanNamesForTypeIn
cludingAncestors(BeanFactoryUtils.java:187)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.
findAutowireCandidates(DefaultListableBeanFactory.java:999)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.
doResolveDependency(DefaultListableBeanFactory.java:957)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.
resolveDependency(DefaultListableBeanFactory.java:855)
        at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanP
ostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.j
ava:480)
        at org.springframework.beans.factory.annotation.InjectionMetadata.inject
(InjectionMetadata.java:87)
        at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanP
ostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java
:289)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBean
Factory.populateBean(AbstractAutowireCapableBeanFactory.java:1185)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBean
Factory.doCreateBean(AbstractAutowireCapableBeanFactory.java:537)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBean
Factory.createBean(AbstractAutowireCapableBeanFactory.java:475)
        at org.springframework.beans.factory.support.AbstractBeanFactory$1.getOb
ject(AbstractBeanFactory.java:304)
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistr
y.getSingleton(DefaultSingletonBeanRegistry.java:228)
        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBe
an(AbstractBeanFactory.java:300)
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean
(AbstractBeanFactory.java:195)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.
preInstantiateSingletons(DefaultListableBeanFactory.java:700)
        at org.springframework.context.support.AbstractApplicationContext.finish
BeanFactoryInitialization(AbstractApplicationContext.java:760)
        at org.springframework.context.support.AbstractApplicationContext.refres
h(AbstractApplicationContext.java:482)
        at org.springframework.context.support.ClassPathXmlApplicationContext.<i
nit>(ClassPathXmlApplicationContext.java:139)
        at org.springframework.context.support.ClassPathXmlApplicationContext.<i
nit>(ClassPathXmlApplicationContext.java:93)
        at com.alibaba.dubbo.container.spring.SpringContainer.start(SpringContai
ner.java:50)
        at com.alibaba.dubbo.container.Main.main(Main.java:80)
,
]

而且这个信息不停的打，并且看到的全是xxxMapper？

难道是mybatis的mapper代理类的创建出现了问题？

尝试本地通过代码的方式启动服务，没有任何问题。

又尝试本地通过打出的zip包，通过java -jar的方式启动，也没有任何问题。

这个时候就很头疼了，定位不到问题，而且问题不能重现。

网上能搜索到关于mybatis启动报Stack overflow的错误，难道我们这个问题跟他也有关系？于是尝试看一下mybatis的mapper代理自动创建的相关资料。

通过这篇文章

当MapperFactoryBean实例生成之后，Spring给它注入SqlSessionTemplate。而注入SqlSessionTemplate的过程中会向容器获取所有的Dao，对于已经在容器中的Dao所对应的bean可以直接获取返回，若还没有创建bean，则Spring又会先创建这个Dao的MapperFactoryBean。创建MapperFactoryBean的时候会再次注入SqlSessionTemplate。就这样一直循环下去，直到所有的Dao都已经创建完毕，这个过程才算结束。

看来跟mybatis的关系应该很大，网上有有说mybatis Mapper有导致过stack overflow的错误，新想如果是stack overflow肯定应该是有明确的异常抛出，于是也是抱着尝试调整一下jvm的参数看看是否有惊喜。

-Xms1024m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=256m -Xss256k

stack overflow应该调整Xss参数大小（-Xss512k）调整后重启，竟然成功了！竟然成功了！竟然成功了！

太不可思议了难道是stack overflow异常被吃掉了？而且mapper在创建的时候是递归，递归的层次越深越消耗stack大小，然后具体搜索mybatis导致stack异常的信息看到了这篇文章，上面就是说mybatis-spring工具包有问题将异常吃掉了，具体mybatis-spring中的那段代码我还在定位，定位好了在更新文章

解决方法

调整xss参数，从xss256k调整为xss512k

比如说我们使用prd环境数据迁移到st环境为例来叙述一下具体的步骤。

第一步：从prd环境zookeeper服务器的数据目录下复制最新的日志和快照文件。

先去zookeeper的安装目录下找到zookeeper的conf文件，例如：

$> cd /usr/local/zookeeper/conf
$> cat zoo.cfg

打开zoo.cfg文件找到具体配置的zookeeper的data目录，例如：

# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just
# example sakes.
dataDir=/var/zookeeper

进入到dataDir下的version-2文件夹，version-2文件夹下存放的是zookeeper的日志和镜像文件，我们找到最新的日志和镜像文件，例如：

$> cd /var/zookeeper/version-2
$> ls -ah
-rw-r--r-- 1 zookeeper zookeeper 67108880 Sep 27 17:20 log.909e2d252
-rw-r--r-- 1 zookeeper zookeeper 10408329 Sep 27 17:01 snapshot.909e2d250

找到最新的日志和快照文件，例如上面的：log.909e2d252和snapshot.909e2d250

日志文件存放zookeeper全部数据记录 ，快照文件则是内存增量文件。

ps.这里要注意找最新的日志和快照文件

zookeeper的日志和镜像文件的清理可以看这篇文章：Zookeeper事务日志和snapshot清理方式

第二步：传输日志和快照文件

如果st和prd网络是通的话可以通过scp的方式复制过去，如果网络不通通过中转站来过渡。

第三步：停掉需要恢复数据的zk服务，删除数据目录下的文件，复制刚才的两个文件到数据目录下

假设需要恢复数据的服务器上zookeeper数据目录也是在/var/zookeeper下

$> rm -fr /var/zookeeper/*
$> cp log.909e2d252 snapshot.909e2d250 /var/zookeeper
$> cd /usr/local/zookeeper/bin
$> ./zkServer.sh start

如果是三台需要全部服务停掉，恢复其中的一台，然后等数据恢复完成后，再启动其余的两台服务让zk自己同步数据过去

第四步：验证数据是否真的恢复了

$> cd /usr/local/zookeeper/bin
$> ./zkCli.sh
$> ls /

ls查看zk中的数据.

Zookeeper日志与镜像文件的分析可以参考这篇文章：ZooKeeper日志与快照文件简单分析

一、中心化的工作流

中心化的工作流又叫做SVN-style,适用于熟悉svn的管理流程来过渡到git（分布式版本控制系统），如果你的开发团队成员已经很熟悉svn，集中式工作流让你无需去适应一个全新流程就可以体验Git带来的收益。这个工作流也可以作为向更Git风格工作流迁移的友好过渡，入下图所示：

像SVN一样，集中式工作流以中央仓库作为项目所有修改的单点实体。相比SVN缺省的开发分支trunk，Git叫做master，所有修改提交到这个分支上。该工作流只用到master这一个分支。
开发者开始先克隆中央仓库。在自己的项目拷贝中，像SVN一样的编辑文件和提交修改；但修改是存在本地的，和中央仓库是完全隔离的。开发者可以把和上游的同步延后到一个方便时间点。
要发布修改到正式项目中时，开发者要把本地master分支的修改『推（push）』到中央仓库中。这相当于svn commit操作，但push操作会把所有还不在中央仓库的本地提交都推上去，下图所示：

为什么会有冲突，冲突的原因

使用svn-style的方式避免不了会遇到冲突，冲突的解决尤为重要，中央仓库代表了正式项目（git里是master，svn里是trunk），所以提交历史应该被尊重且是稳定不变的。如果开发者本地的提交历史和中央仓库有分歧，Git会拒绝push提交否则会覆盖已经在中央库的正式提交。

在开发者提交自己功能修改到中央库前，需要先fetch在中央库的新增提交，rebase自己提交到中央库提交历史之上。这样做的意思是在说，我要把自己的修改加到别人已经完成的修改上，最终的结果是一个完美的线性历史，就像以前的SVN的工作流中一样。如果本地修改和上游提交有冲突，Git会暂停rebase过程，给你手动解决冲突的机会。

举例说明

让我们举一个例子来理解一下中心化工作流-svn-style

比如说：wms项目组有两个开发人员：小明、小健，看他们是如何开发自己的功能并提交到中央仓库上的。

第一步：小明、小健从中央仓库克隆代码

git clone http://gitlab.xxx.com/demo/gitflow-demo.git

ps.克隆仓库时Git会自动添加远程别名origin指向中央仓库，不动请参考：git clone --help

克隆代码入下图示例：

小明开发新功能：

小明使用标准的Git过程开发功能：编辑、暂存（Stage）和提交，这里注意不进行push操作，只做本地commit提交到本地仓库

git status # 查看本地仓库的修改状态
git add # 暂存文件
git commit # 提交文件

这些操作都是本地的提交操作，小明可以反复的按照需求来进行代码修改，不需要担心中央仓库的改变和小健自己本地的改变。

小明开发功能都在本地上进行就如下图示例：

小健开发新功能

小健也是一样使用标准的Git过程开发功能，编辑、暂存、提交，他和小明一样不需要关系中央仓库的改变和小明自己本地的改变，所有的提交都是私有的，都是在自己的本地仓库中。

小健开发功能都在本地上进行就如下图所示：

小明开发好了功能想发布了

小明把他的本地仓库修改的代码push到中央仓库，使用下面命令

git push origin master

ps. origin是在小明克隆仓库时Git创建的远程中央仓库别名。master参数告诉Git推送的分支

ps. 我们这里假设团队中只有两个人（小明、小健），由于中央仓库自从小明克隆以来还没有被更新过，所以push操作不会有冲突，成功完成。

小明把他自己的本地代码push到中央仓库就如下图所示：

小健开发好了功能也想发布了

小健也是使用git push命令来推送自己本地仓库的改动到中央仓库，使用下面命令

git push origin master

但是此时origin已经由于小明在之前推送了小明本地的代码上去，因此已经和小健本地的代码产生了分歧，推送会被拒绝，入下图所示：

拒绝的信息如下：

$ git push origin master
To http://gitlab.xxx.com/demo/gitflow-demo.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'http://gitlab.xxx.com/demo/gitflow-demo.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

遇到这种问题我们该怎么解决了？

小健可以使用pull操作合并上游的修改到自己的仓库中，git的pull操作类似于svn的update操作，拉取所有上游小明提交命令到小健的本地仓库，但是要加上–rebase参数，例如下面命令：

git pull --rebase origin master

这里特别解释一下上面命令的实际操作原理

–rebase选项告诉git把小健的提交移到（同步了中央仓库修改后的master分支）的顶部（head），也就是说它会先把小健本地分支的本地提交先移除掉，移动到一旁，然后把小健的本地分支同步中央仓库的最新版本（小明提交的记录），然后把刚刚移除了（小健本地的修改）再提交回小健的本地分支（已同步了最新中央仓库的代码，也就是说小明的代码）。

不加rebase的话git会在xiaoming和xiaojian的提交后再进行一次merge操作从而就会多了一个merge的提交记录，加了rebase的话xiaojian的提交已经包含了与xiaoming代码的冲突，因此不会多一个merge操作。

rebase（没有冲突）操作的过程例如下图所示：

rebase（存在冲突）操作的过程例如下图所示：

ps. git会暂定rebase操作直到你去解决了冲突之后执行git rebase --continue来继续进行操作.

rebase实操记录

下面是rebase的操作实践，xiaojian执行git pull --rebase origin master，比如说xiaoming和xiaojian冲突到了同一个文件上会显示出下面的信息，例如：

$ git pull --rebase origin master
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From http://gitlab.xxx.com/demo/gitflow-demo
 * branch            master     -> FETCH_HEAD
   788c7f3..9c7c9d2  master     -> origin/master
First, rewinding head to replay your work on top of it...
Applying: xiaojian 提交
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M       README.md
Falling back to patching base and 3-way merge...
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Patch failed at 0001 xiaojian 提交
The copy of the patch that failed is found in: .git/rebase-apply/patch
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".

如果装了小乌龟或者sourcetree目录下文件会显示冲突警告图标

根据上面的警告我们需要手动的解决冲突，解决完冲突使用git add/rm <conflicted_files>命令标记解决冲突完毕，再执行git rebase --continue继续下一步操作。

ps. 如果这个时候后悔执行了git pull --rebase origin master想撤销怎么办？可以执行git rebase --abort撤销rebase操作。

接下来是xiaojian执行push到中央仓库并且解决冲突的脚本记录如下：

手动解决冲突
$ git add README.md
$ git rebase --continue
Applying: xiaojian 提交
$ git push origin master
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 305 bytes | 305.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To http://gitlab.xxx.com/demo/gitflow-demo.git
   9c7c9d2..87aed2d  master -> master

然后我们去gitlab上看我们的提交记录是个什么样子的，例如下图：

ps.提交记录非常的清晰明了而且是按照push仓库的顺序来显示的提交记录，这个样子也是我们希望看到的。

但是往往并没有这么顺利，理想很好现实确实各种问题。

比如说git pull的时候忘记添加--rebase参数了怎么办？

如果忘加了--rebase这个选项，pull操作仍然可以完成，但每次pull操作在同步中央仓库中别人的修改时，需要提交合并代码的记录从而导致提交历史中会多一个『合并提交』的记录。

例如下面所示：

$ git pull origin master
From http://gitlab.xxx.com/demo/gitflow-demo
 * branch            master     -> FETCH_HEAD
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.
手动解决完冲突
$ git add .
$ git commit -m "合并冲突"
[master 9fab0c8] 合并冲突
$ git push origin master
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 581 bytes | 290.00 KiB/s, done.
Total 6 (delta 2), reused 0 (delta 0)
To http://gitlab.xxx.com/demo/gitflow-demo.git
   f862f27..9fab0c8  master -> master

然后我们去gitlab上看我们的提交记录是个什么样子的，例如下图：

ps. 会多出一个合并的提交，而且查看tree型图会发现不是一个线性的轨迹

如果使用的是小乌龟sourcetree这种工具合并冲突会是什么样子？让我们演示一下：

首先

手动解决完冲突，选择标记为已经解决

我们需要把解决的冲突提交上去

自动生成的comment是Merge branchmasterxxxxxxx

提交完成后右键菜单选择git push

这个时候我们去gitlab上看我们的提交记录是个什么样子的，例如下图：

示例总结以及注意事项

所以我们建议对于集中式工作流，最好是使用rebase，而不是使用merge生成一个合并提交

作者：鲁小憨
链接：https://www.jianshu.com/p/7182b8751e75
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

在 RPC Benchmark Round 1 中，Turbo 性能炸裂表现强悍，并且在 listUser 这一项目中，取得了 10x dubbo 性能的好成绩。本文将介绍 Turbo 强悍性能背后的原理，并探讨如何编写高性能的 RPC 框架。

过早的优化是万恶之源？

这句话是 The Art of Computer Programming 作者，图领奖得主 Donald Knuth 大神说的。不过对于框架设计者而言，这句话并不正确。在设计一款高性能的基础框架时，必须始终重视性能优化，并将性能测试贯穿于整个设计开发过程中。这方面做到极致的类库有 Disruptor JCTools Agrona DSL-JSON 等等，这几个高性能类库都坚持一个原则：不了解性能的外部类库坚决不用，如果现有的类库不能满足性能要求，那就重新设计一个。作为 Turbo 的设计者，我也尽量坚持这一原则，努力做到 Benchmark 驱动开发。

JMH 让 Benchmark 驱动开发成为可能

在 JMH 出现之前，要对某个类库进行微基准性能测试是一件非常困难的事情。很难保证公平的测试条件，预热次数难以确定，预热效果也不好观察。JMH 的出现让性能测试变得 标准化 简单化，也让 Benchmark 驱动开发成为可能。Turbo 在开发过程中用 JMH 进行了充分的 Benchmark，以确定核心环节的性能开销，选择合适的实现方案。更多关于 JMH 的介绍请参考下面的链接：

• OpenJDK: jmh
• JMH - Java Microbenchmark Harness
• ImportNew JMH简介

RPC 的主要流程

1. 客户端 获取到 UserService 接口的 Refer: userServiceRefer
2. 客户端 调用 userServiceRefer.verifyUser(email, pwd)
3. 客户端 获取到 请求方法 和 请求数据
4. 客户端 把 请求方法 和 请求数据 序列化为 传输数据
5. 进行网络传输
6. 服务端 获取到 传输数据
7. 服务端 反序列化获取到 请求方法 和 请求数据
8. 服务端 获取到 UserService 的 Invoker: userServiceInvoker
9. 服务端 userServiceInvoker 调用 userServiceImpl.verifyUser(email, pwd) 获取到 响应结果
10. 服务端 把 响应结果 序列化为 传输数据
11. 进行网络传输
12. 客户端 接收到 传输数据
13. 客户端 反序列化获取到 响应结果
14. 客户端 userServiceRefer.verifyUser(email, pwd) 返回 响应结果

整个流程中对性能影响比较大的环节有：序列化[4, 7, 10, 13]，方法调用[2, 3, 8, 9, 14]，网络传输[5, 6, 11, 12]。本文后续内容将着重介绍这3个部分。

序列化方案

Java 世界最常用的几款高性能序列化方案有 Kryo Protostuff FST Jackson Fastjson。只需要进行一次 Benchmark，然后从这5种序列化方案中选出性能最高的那个就行了。DSL-JSON 使用起来过于繁琐，不在考虑之列。Colfer Protocol Thrift 因为必须预先定义描述文件，使用起来太麻烦，所以不在考虑之列。至于 Java 自带的序列化方案，早就因为性能问题被大家所抛弃，所以也不考虑。下面的表格列出了在考虑之列的5种序列化方案的性能。

• User 序列化+反序列化 性能

• 包含15个 User 的 Page 序列化+反序列化 性能

从这个 benchmark 中可以得出明确的结论：二进制协议的 protostuff kryo fst 要比文本协议的 jackson fastjson 有明显优势；文本协议中，jackson(开启了afterburner) 要比 fastjson 有明显的优势。

无法确定的是：3个二进制协议到底哪个更好一些，毕竟 速度 和 size 对于 RPC 都很重要。直观上 kryo 或许是最佳选择，而且 kryo 也广受各大型系统的青睐。不过最终还是决定把这3个类库都留作备选，通过集成传输模块后的 Benchmark 来决定选用哪个。

最终的结果也还是各有千秋难以抉择，所以 Turbo 保留了 protostuff 和 kryo 的实现，并允许用户自行替换为自己的实现。

方法调用

可用的 动态方法调用 方案有：Reflection ClassGeneration MethodHandle。Reflection 是最古老的技术，据说性能不佳。ClassGeneration 动态类生成，从原理上说应该是跟直接调用一样的性能。MethodHandle 是从 Java 7 开始出现的技术，据说能达到跟直接调用一样的性能。实际结果如下：

结论非常明显：使用类生成技术的 javassist 跟直接调用几乎一样的性能，就用 javassist 了。

MethodHandle 表现并没有宣传的那么好，怎么回事？原来 MethodHandle 只有在明确知道调用 参数数量 参数类型 的情况下才能调用高性能的 invokeExact(Object… args)，所以它并不适合作为动态调用的方案。

As is usual with virtual methods, source-level calls to invokeExact and invoke compile to an invokevirtual instruction. More unusually, the compiler must record the actual argument types, and may not perform method invocation conversions on the arguments. Instead, it must push them on the stack according to their own unconverted types. The method handle object itself is pushed on the stack before the arguments. The compiler then calls the method handle with a symbolic type descriptor which describes the argument and return types.
refer: https://docs.oracle.com/javase/7/docs/api/java/lang/invoke/MethodHandle.html

网络传输

Netty 已经成为事实上的标准，所有主流的项目现在使用的都是 Netty。Mina Grizzly 已经失去市场，所以也就不用考虑了。还好也不至于这么无聊，Aeron 的闪亮登场让 Netty 多了一个有力的竞争对手。Aeron 是一个可靠高效的 UDP 单播 UDP 多播和 IPC 消息传递工具。性能是消息传递中的关键。Aeron 的设计旨在达到 高吞吐量 低开销 和 低延迟。实际效果到底如何呢？很遗憾，在 RPC Benchmark Round 1 中的表现一般。跟他们开发团队沟通后，最终确认其无法对超过 64k 的消息进行 zero-copy 处理，我觉得这可能是 Aeron 表现不佳的一个原因。Aeron 或许更适合 微小消息 极端低延迟 的场景，而不适用于更加通用的 RPC 场景。所以暂时还没有出现能够跟 Netty 一争高下的通用网络传输框架，现阶段 Netty 依然是 RPC 系统的最佳选择。

• existUser 判断某个 email 是否存在

消息格式

我们先来看一下 Dubbo 的消息格式

public class RpcInvocation implements Invocation, Serializable {
    private String methodName;
    private Class<?>[] parameterTypes;
    private Object[] arguments;
    ...
}

可以说是非常经典的设计，Client 必须告知 Server 要调用的 方法名称 参数类型 参数。Server 获取到这3个参数后，通过 方法名称 com.alibaba.service.auth.UserService.verifyUser 和
参数类型 (String, String) 获取到 Invoker，然后通过 Invoker 实际调用 userServiceImpl 的 verifyUser(String, String) 方法。其他的众多 RPC 框架也都采取了这一经典设计。

但是，这是正确的做法吗？当然不是，这种做法非常浪费空间，每次请求消息体的大概内存布局应该是下面的样子：

public boolean verifyUser(String email, String pwd);

|com.alibaba.service.auth.UserService.verifyUser|java.lang.String,java.lang.String|实际的参数|

啰里啰嗦的，浪费了 80 byte 来定义 方法 和 参数，并没有比 http+json 的方式高效多少。实际的 性能测试 也证明了这一点，undertow+jackson 要比 dubbo motan 的成绩都要好。

那什么才是正确的做法？Turbo 在消息格式上做出了非常大的改变。

public class Request implements Serializable {
    private int requestId;
    private int serviceId;
    private MethodParam methodParam;
    ...
}

大致的内存布局：

public boolean verifyUser(String email, String pwd);
|int|int|实际的参数|

高效多了，只用了 4 byte 就做到了 方法 和 参数 的定义。大大减小了 传输数据 的 size，同时 int 类型的 serviceId 也降低了 Invoker 的查找开销。

看到这里，有同学可能会问：那岂不是要为每个方法定义一个唯一 id ？
答案是不需要的，Turbo 解决了这一问题，详情参考 TurboConnectService 。

MethodParam 简介

MethodParam 才是 Turbo 性能炸裂的真正原因。其基本原理是利用 ClassGeneration 对每个 Method 都生成一个 MethodParam 类，用于对方法参数的封装。这样做的好处有：

1. 减少基本数据类型的 装箱 拆箱 开销
2. 序列化时可以省略掉很多类型描述，大大减小 传输消息 的 size
3. 使 Invoker 可以高效调用 被代理类 的方法
4. 统一 RPC 和 REST 的数据模型，简化 序列化 反序列化 实现
5. 大大加快 json 格式数据 反序列化 速度

//方法 test(long id, int value) 将会生成下面的 MethodParam 类:     
public class TestService_test_2_MethodParam implements MethodParam {
    private long id;
    private int value;
     
    public long $param0() { return this.id; }
    public int $param1() { return this.value; }

    //... getters and setters
     
    public TestService_test_2_MethodParam(long id, int value) {
        this.id = id;
        this.value= value;
    }
}

序列化的进一步优化

大部分 RPC 框架的 序列化 反序列化 过程都需要一个中间的 bytes

序列化过程：User > bytes > ByteBuf
反序列化过程：ByteBuf > bytes > User

而 Turbo 砍掉了中间的 bytes，直接操作 ByteBuf，实现了 序列化 反序列化 的 zero-copy，大大减少了 内存分配 内存复制 的开销。具体实现请参考 ProtostuffSerializer 和 Codec。

对于已知类型和已知字段，Turbo 都尽量采用 手工序列化 手工反序列化 的方式来处理，以进一步减少性能开销。

ObjectPool

常见的几个 ObjectPool 实现性能都很差，反而很容易成为性能瓶颈。Stormpot 性能强悍，不过存在偶尔死锁的问题，而且作者也停止维护了。HikariCP 性能不错，不过其本身是一款数据库连接池，用作 ObjectPool 并不称手。我的建议是尽量避免使用 ObjectPool，转而使用替代技术。更重要的是 Netty 的 Channel 是线程安全的，并不需要使用 ObjectPool 来管理。只需要一个简单的容器来存储 Channel，用的时候使用 负载均衡策略 选出一个 Channel 出来就行了。

基础类库优化

除了上述的关键流程优化，Turbo 还做了大量基础类库的优化

• AtomicMuiltInteger 多个 int 的原子性操作
• ConcurrentArrayList 无锁并发 List 实现，比 CopyOnWriteArrayList 的写入开销低，O(1) vs O(n)
• ConcurrentIntToObjectArrayMap 以 int 数组为底层实现的无锁并发 Map，读多写少情况下接近直接访问字段的性能，读多写多情况下是 ConcurrentHashMap 性能的 5x
• ConcurrentIntegerSequencer 快速序号生成器，并发环境下是 AtomicInteger 性能的10x
• ObjectId 全局唯一 id 生成器，是 Java 自带 UUID 性能的 200x
• HexUtils 查表 + 批量操作，是 Netty 和 Guava 实现的 2x~5x
• URLEncodeUtils 基于 HexUtils 实现，是 Java 和 Commons 实现的 2x，Guava 实现的 1.1x (Guava 只有 urlEncode 实现，无 urlDecode 实现)
• ByteBufUtils 实现了高效的 ZigZag 写入操作，最高可达通常实现的 4x

上面的内容仅介绍了作者认为重要的东西，更多内容请直接查看 Turbo 源码

不足之处

• 有很多优化是毫无价值的，Donald Knuth 大神说得很对
• 强制必须使用 CompletableFuture 作为返回值导致了一些性能开销
• 滥用 ClassGeneration，而且并没有考虑类的卸载，这方面需要改进
• 实现了 UnsafeStringUtils，这是个危险的黑魔法实现，需要重新思考下
• 对性能的追求有点走火入魔，导致了很多地方的设计过于复杂

作者：鲁小憨
链接：https://www.jianshu.com/p/cbcdf05eaa5c
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

在 RPC Benchmark Round 1 中 turbo 的成绩一骑绝尘，实力碾压众 rpc 框架。对此，很多人表示不服气，认为作者既是运动员又是裁判员有失公平。所以我认为有必要解释一下 rpc-benchmark 的公正性，以及为什么 turbo 能够如此强悍。

参考对象

rpc-benchmark 灵感源自 techempower-benchmarks，为了能够评测众多服务器框架，techempower-benchmarks 提供了6个测试用例：

• JSON serialization

This test exercises the framework fundamentals including keep-alive support, request routing, request header parsing, object instantiation, JSON serialization, response header generation, and request count throughput.

• Single database query

This test exercises the framework’s object-relational mapper (ORM), random number generator, database driver, and database connection pool.

• Multiple database queries

This test is a variation of Test #2 and also uses the World table. Multiple rows are fetched to more dramatically punish the database driver and connection pool. At the highest queries-per-request tested (20), this test demonstrates all frameworks’ convergence toward zero requests-per-second as database activity increases.

• Fortunes

This test exercises the ORM, database connectivity, dynamic-size collections, sorting, server-side templates, XSS countermeasures, and character encoding.

• Database updates

This test is a variation of Test #3 that exercises the ORM’s persistence of objects and the database driver’s performance at running UPDATE statements or similar. The spirit of this test is to exercise a variable number of read-then-write style database operations.

• Plaintext

This test is an exercise of the request-routing fundamentals only, designed to demonstrate the capacity of high-performance platforms in particular. Requests will be sent using HTTP pipelining. The response payload is still small, meaning good performance is still necessary in order to saturate the gigabit Ethernet of the test environment.

techempower-benchmarks 规则都是公开的，代码都是开放的。任何人觉得xx框架写得不好，配置有问题，都可以来提交自己的 Pull Request 。一句话，不服气的话就来提交代码。

测试用例

不过 techempower-benchmarks 对比的都是服务器框架，并不能用来测试 rpc 的性能，作为学习模仿者，我创建了 rpc-benchmark 这个项目。 rpc-benchmark 提供了4个测试用例：

• boolean existUser(String email), 判断某个 email 是否存在
  输入是很短的字符串，输出是 bool 值，这个测试用例用于衡量小 Request 小
  Response 的性能。

• boolean createUser(User user), 添加一个 用户
  输入是一个 User 的对象，输出是 bool 值，这个测试用例用于衡量大 Request 小 Response 的性能。

• User getUser(long id), 根据 id 获取一个用户
  输入是一个 long 类型的值，输出是 User 对象，这个测试用例用于衡量小 Request 大 Response 的性能。

• Page listUser(int pageNo), 获取用户列表
  输入是 int 类型的值，输出是一个包含15个 User 的列表，这个测试用例用于衡量小 Request 超大 Response 的性能。

这4个测试用例构成了一个基本的业务逻辑： 用户注册管理。非常具有代表性，并且没有脱离现实使用场景。有些测试用例可能会注重衡量字符串的传输速度，从4字节 64字节 … 64k字节 依次测起，这样的测试用例就过于脱离现实，没有太多的实际意义。毕竟作为 rpc 框架，除了传输速度，序列化速度其实也是非常重要的。而仅仅用字符串来测试仅能测试出框架的传输速度，并不能有效衡量序列化的性能，也不能衡量整体的 rpc 性能。

测试工具

因为每个 rpc 框架都有自己的 序列化协议 传输协议，所以 rpc-benchmark 不能像 techempower-benchmarks 一样直接使用 wrk 作为测试工具，只能每个框架都编写测试用的 客户端实现。

客户端实现 使用的工具是JMH，这个工具 Java 开发团队自己也在使用。正确的性能测试在之前并不是一件简单的事情，JMH 的出现让性能测试真正的 标准化 简单化。更多关于 JMH 的介绍可以参考下面的链接。

• JMH - Java Microbenchmark Harness
• ImportNew JMH简介

测试方法

测试的过程是先进行10次预热，然后才开始真正的3次测试（JMH的“每次”执行实际上是执行很多次，更好的翻译其实应该是“每轮”）。刚开始使用的是5次预热，但是后来发现 http 传输协议的 undertow grpc 等框架都比较慢热，需要更多的预热次数。完整的测试要跑起来依然有点费劲，需要配置很多环境。不过如果你只是想研究下某个框架的代码实现的话，完全可以更简单一些。拉下代码来直接导入到 Eclipse/IDEA ，配置好hosts，启动 Server，然后启动相应的 Client 就好了。

为什么把 undertow springboot netty 也作为了测试对象

按照 wiki 的定义，这三个确实不能认为是 rpc ，不过简单封装之后他们都可以作为 rpc 使用。加入这几个更多的是为给 rpc 框架的实现者提供一个参考，作为基础的协议层性能是怎么样的？作为springcloud 的底层实现，springboot 其实代表了springcloud 的性能。undertow 证明了 http+json 并不比 tcp+binary 慢太多，其速度甚至比 dubbo motan 还要快不少。同时也是为了告诉喷子们，并不是说你用了高性能的 netty+protopuff 就能比 turbo 快，turbo 能碾压众框架并不只是靠简单的拼积木就能做到的。

不足之处

仅1个客户端32个线程其实是非常不严谨的，正确的做法应该是从1个线程一直到32k个线程逐步增加，从1台客户端机器到1000台客户端机器逐步增加（客户端数量 线程数量 应该是一个笛卡尔积）。不过每轮测试实在都太耗费时间了，而且阿里云的服务器也不便宜，所以只能作罢。后续如果有云服务器厂商赞助的话，可以考虑把这块给做起来。

turbo为什么如此强悍

篇幅有限写不开了，下篇再说吧。

问题描述

多任务同时处理时会报出如下NPE异常，堆栈信息如下：

2018-08-10 18:16:10.938 [xxxExecutor-2] ERROR c.j.bmc.mq.listener.xxxResultListener 
org.mybatis.spring.MyBatisSystemException: nested exception is org.apache.ibatis.exceptions.PersistenceException:
### Error querying database.  Cause: java.lang.NullPointerException
### Cause: java.lang.NullPointerException
    at org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:75) ~[mybatis-spring-1.2.2.jar:1.2.2]
    at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:371) ~[mybatis-spring-1.2.2.jar:1.2.2]
    at com.sun.proxy.$Proxy21.selectList(Unknown Source) ~[na:na]
    at org.mybatis.spring.SqlSessionTemplate.selectList(SqlSessionTemplate.java:198) ~[mybatis-spring-1.2.2.jar:1.2.2]
    at org.apache.ibatis.binding.MapperMethod.executeForMany(MapperMethod.java:119) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:63) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:52) ~[mybatis-3.2.7.jar:3.2.7]
    at com.sun.proxy.$Proxy49.findBillBillingTask(Unknown Source) ~[na:na]
    at com.xxx.service.impl.XXXServiceImpl.findBillBillingTask(XXXServiceImpl.java:118) ~[bmc-service-0.0.1-SNAPSHOT.jar:na]
    at com.xxx.service.impl.XXXServiceImpl$$FastClassByCGLIB$$7d4463f0.invoke(<generated>) ~[spring-core-4.0.0.RELEASE.jar:na]
    at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204) ~[spring-core-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:713) ~[spring-aop-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157) ~[spring-aop-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:98) ~[spring-tx-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:262) ~[spring-tx-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:95) ~[spring-tx-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:646) ~[spring-aop-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at com.xxx.service.impl.XXXServiceImpl$$EnhancerByCGLIB$$32d6287d.findBillBillingTask(<generated>) ~[spring-core-4.0.0.RELEASE.jar:na]
    at com.xxx.service.impl.XXXResultServiceImpl.saveBillBillingTask(XXXResultServiceImpl.java:213) ~[bmc-service-0.0.1-SNAPSHOT.jar:na]
    at com.xxx.service.impl.XXXResultServiceImpl.disposeBillBillingResult(XXXResultServiceImpl.java:193) ~[bmc-service-0.0.1-SNAPSHOT.jar:na]
    at com.xxx.service.impl.XXXResultServiceImpl$$FastClassByCGLIB$$5e8db258.invoke(<generated>) ~[spring-core-4.0.0.RELEASE.jar:na]
    at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204) ~[spring-core-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:713) ~[spring-aop-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157) ~[spring-aop-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:98) ~[spring-tx-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:262) ~[spring-tx-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:95) ~[spring-tx-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:646) ~[spring-aop-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at com.xxx.service.impl.XXXResultServiceImpl$$EnhancerByCGLIB$$8d251e5.disposeBillBillingResult(<generated>) ~[spring-core-4.0.0.RELEASE.jar:na]
    at com.xxx.XXXListener.receiveMessage(BillBillingResultListener.java:92) ~[bmc-main-0.0.1-SNAPSHOT.jar:na]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_79]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_79]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_79]
    at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_79]
    at org.springframework.util.MethodInvoker.invoke(MethodInvoker.java:273) [spring-core-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.jms.listener.adapter.MessageListenerAdapter.invokeListenerMethod(MessageListenerAdapter.java:466) [spring-jms-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.jms.listener.adapter.MessageListenerAdapter.onMessage(MessageListenerAdapter.java:357) [spring-jms-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.jms.listener.adapter.MessageListenerAdapter.onMessage(MessageListenerAdapter.java:332) [spring-jms-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:537) [spring-jms-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:497) [spring-jms-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:468) [spring-jms-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:325) [spring-jms-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263) [spring-jms-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1104) [spring-jms-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:998) [spring-jms-4.0.0.RELEASE.jar:4.0.0.RELEASE]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_79]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_79]
    at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
Caused by: org.apache.ibatis.exceptions.PersistenceException:
### Error querying database.  Cause: java.lang.NullPointerException
### Cause: java.lang.NullPointerException
    at org.apache.ibatis.exceptions.ExceptionFactory.wrapException(ExceptionFactory.java:26) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:111) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:102) ~[mybatis-3.2.7.jar:3.2.7]
    at sun.reflect.GeneratedMethodAccessor203.invoke(Unknown Source) ~[na:na]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_79]
    at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_79]
    at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:358) ~[mybatis-spring-1.2.2.jar:1.2.2]
    ... 48 common frames omitted
Caused by: java.lang.NullPointerException: null
    at org.apache.ibatis.reflection.property.PropertyTokenizer.<init>(PropertyTokenizer.java:30) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.reflection.MetaObject.getValue(MetaObject.java:107) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.scripting.xmltags.DynamicContext$ContextMap.get(DynamicContext.java:97) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.scripting.xmltags.DynamicContext$ContextAccessor.getProperty(DynamicContext.java:116) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.ognl.OgnlRuntime.getProperty(OgnlRuntime.java:1657) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.ognl.ASTProperty.getValueBody(ASTProperty.java:92) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.ognl.SimpleNode.getValue(SimpleNode.java:210) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.ognl.ASTNotEq.getValueBody(ASTNotEq.java:49) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.ognl.SimpleNode.getValue(SimpleNode.java:210) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.ognl.Ognl.getValue(Ognl.java:333) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.ognl.Ognl.getValue(Ognl.java:413) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.ognl.Ognl.getValue(Ognl.java:395) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.scripting.xmltags.OgnlCache.getValue(OgnlCache.java:48) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.scripting.xmltags.ExpressionEvaluator.evaluateBoolean(ExpressionEvaluator.java:32) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.scripting.xmltags.IfSqlNode.apply(IfSqlNode.java:33) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.scripting.xmltags.MixedSqlNode.apply(MixedSqlNode.java:32) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.scripting.xmltags.DynamicSqlSource.getBoundSql(DynamicSqlSource.java:40) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.mapping.MappedStatement.getBoundSql(MappedStatement.java:278) ~[mybatis-3.2.7.jar:3.2.7]
    at org.apache.ibatis.executor.CachingExecutor.query(CachingExecutor.java:75) ~[mybatis-3.2.7.jar:3.2.7]
    at sun.reflect.GeneratedMethodAccessor205.invoke(Unknown Source) ~[na:na]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_79]
    at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_79]
    at org.apache.ibatis.plugin.Invocation.proceed(Invocation.java:49) ~[mybatis-3.2.7.jar:3.2.7]
    at com.github.pagehelper.util.SqlUtil.doIntercept(SqlUtil.java:175) ~[pagehelper-4.2.1.jar:na]
    at com.github.pagehelper.util.SqlUtil.intercept(SqlUtil.java:84) ~[pagehelper-4.2.1.jar:na]
    at com.github.pagehelper.PageHelper.intercept(PageHelper.java:50) ~[pagehelper-4.2.1.jar:na]
    at org.apache.ibatis.plugin.Plugin.invoke(Plugin.java:60) ~[mybatis-3.2.7.jar:3.2.7]
    at com.sun.proxy.$Proxy53.query(Unknown Source) ~[na:na]
    at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:108) ~[mybatis-3.2.7.jar:3.2.7]
    ... 53 common frames omitted

分析过程

通常，有堆栈数据的时候就很容分析出问题的原因。但是经过查看相关代码后发现触发点操作逻辑非常简单，不太会出现该异常。

于是就考虑从日志的细节分析问题。

先查看业务代码。该代码使用一个非空的VO对象作为查询条件，提交给Mapper。

Mapper中，判断各个参数是否为null或者空，然后拼接到SQL中。整个过程非常简单，而且大部分是成功执行的。

通过以上判断，可以认为不是业务代码的问题，极有可能是mybatis的问题。于是上网进行搜索，得到一些关于偶发NPE问题的描述。

mybatis-3/issues/313

mybatis-3/issues/199

以下问题提及了偶发返回null的情况。

issues-OGNL-121

于是我们又观察反编译代码和日志执行情况，可以看到在SimpleNode.java中的确有非安全的逻辑操作。

日志也有相关的执行过程。

由于没有源代码，所以无法有效的进行Debug，模拟并发操作。因此该问题只能怀疑是这个原因导致的，具体可以在后续

有条件的情况下进行模拟测试。

深入并发测试

在Idea中可以反编译代码，且还原度较高，因此我们做了一次测试。

测试环境

两个Consumer调用Provider，Provider只做数据库查询，且查询中带条件判断。

这里使用Spring test进行测试，以下是Consumer端调用

Provider端定义

查询条件判断

准备好测试环境后，就可以进行测试了。此处还需要注意如何在IntellJ Idea中Debug多线程，具体设置方法请找度娘。

测试过程

同时启动两个Consumer，然后在Provider中的SimpleNode.java中设置断点。

根据之前分析，如果要出现null，则说明getProperty会返回null。

而getValue方法实际调用的逻辑是以下代码：

说明以下的代码返回了null

从代码上及Debug分析，如果要返回null，则很有可能在hasConstantValue=true且constantValue为null。

当然此处的数据已经是我们模拟出并发问题后的结果，也验证了是有可能的。

如果没有出问题的情况时，正常的结果应该是constantValue=id，hasConstantValue=true。

测试过程中，我们发现多个线程调用的对象实际是同一个，如下图中的ASTConst@6075。

根据多线程常见问题处理经验来看，如果多线程操作同一个对象，则要注意其是否存在成员变量。如果有，那还要注意是否做了并发可见性处理。

于是我们看下代码

那我们指导了这里有并发问题，那就好容易模拟了。我们只要在第一个线程中保持一种状态，然后暂停操作。再在另外一个线程中去特定的操作

步骤中正常变更数据。最后再放开第一个线程继续往下执行。由于第一个线程的成员变量已经发生了变化，所以后续的结果就不再是预想的那样

了。

于是就有了如下结果

模拟的关键在于：

1. 多线程操作同一个服务
2. 第一个线程在判断语句处等待第二个线程变更条件值，this.constantValueCalculated变量初始化为false，等第二个线程变更后变为true
3. 第一个线程继续往下执行
4. 第二个线程变更了成员变量的值，this.hasConstantValue变量初始化为false，但是被变更为true，然后等待第一个线程执行
5. 第一个线程用刚更新的值去判断，返回了null值，也就导致了后续的NPE异常

注意：以上说的“等待”只是模拟说法，实际情况会由CPU控制，执行顺序不定。恰巧出现了以上执行流程，则会出现NPE问题。

升级版处理逻辑

在Mybatis的3.4.5版本中，程序采用了volatile修饰符来定义变量，并且在使用上面也注意了赋值的先后顺序。

结论

建议升级mybatis，版本是3.3.0+，提及到新的ognl处理逻辑修复此问题，但是我们要考虑在经过充分测试的前提下进行升级。

问题现象

pc端的附件列表可以正常的下载word、excel文件，并且可以成功的打开，但是当流程流转到钉钉时，在钉钉审批的时候可以通过连接跳转h5来显示附件列表，项目的功能设计初衷是可以在手机端打开预览word、excel文件。

但是发现了奇怪的问题，部分word可以在钉钉中显示，部分word无法显示，例如下图所示：

我们的期望效果如下图所示：

问题分析

我们分别使用手机浏览器（safari）、postman、微信内嵌浏览器、qq内嵌浏览器分别测试无法正常预览的word链接

手机浏览器、微信内嵌浏览器、qq内嵌浏览器均无法打开

使用postman下载在移动端无法打开的word链接，返回的是一段xml，如下：

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<?mso-application progid="Word.Document"?>
<pkg:package xmlns:pkg="http://schemas.microsoft.com/office/2006/xmlPackage"><pkg:part pkg:name="/_rels/.rels"
....

这是个什么鬼？是word的xml格式，问题原因就在这里手机浏览器无法识别word的xml格式，因此再次尝试excel

excel使用的是poi生成直接写的是二级制格式，没有使用xml格式，因此excel是可以在移动端打开预览的。

询问开发word是如何生成的？

生成过程是这样的：使用word编辑好模版，然后另存为xml格式，导入到系统中去，通过FreeMarker替换内容，再将xml写到fastdfs中去后缀给成 ‘.doc’ ,这样下载下来使用office word可以直接打开xml格式的来进行无损渲染。

解决方案

询问业务是否必须要使用word格式文件？我的理解合同项目大多都是给用户只读的文件，建议使用pdf来做，使用jasper生成word模版，通过jasper的java api直接生成pdf，合同后期还要考虑添加水印，pdf更加方便一些。

建议使用pdf来替换word，如果非要使用word，建议生成word二进制格式来替换xml格式，除非不考虑移动端渲染可以使用xml格式的word。

目前java生成word的方式有如下六种方式：

1. Jacob是Java-COM Bridge的缩写，它在Java与微软的COM组件之间构建一座桥梁。使用Jacob自带的DLL动态链接库，并通过JNI的方式实现了在Java平台上对COM程序的调用。DLL动态链接库的生成需要windows平台的支持。该方案只能在windows平台实现，是其局限性。
2. Apache POI包括一系列的API，它们可以操作基于MicroSoft OLE 2 Compound Document Format的各种格式文件，可以通过这些API在Java中读写Excel、Word等文件。他的excel处理很强大，对于word还局限于读取，目前只能实现一些简单文件的操作，不能设置样式。
3. Java2word是一个在java程序中调用 MS Office Word 文档的组件(类库)。该组件提供了一组简单的接口，以便java程序调用他的服务操作Word 文档。 这些服务包括： 打开文档、新建文档、查找文字、替换文字，插入文字、插入图片、插入表格，在书签处插入文字、插入图片、插入表格等。填充数据到表格中读取表格数据 ，1.1版增强的功能： 指定文本样式，指定表格样式。如此，则可动态排版word文档。是一种不错的解决方案。
4. iText是著名的开放源码的站点sourceforge一个项目，是用于生成PDF文档的一个java类库。通过iText不仅可以生成PDF或rtf的文档，而且可以将XML、Html文件转化为PDF文件。功能强大。
5. JSP输出样式，该方案实现简单，但是处理样式有点缺陷，简单的导出可以使用。
6. 用XML做就很简单了。Word从2003开始支持XML格式，大致的思路是先用office2003或者2007编辑好word的样式，然后另存为xml，将xml翻译为FreeMarker模板，最后用java来解析FreeMarker模板并输出Doc。经测试这样方式生成的word文档完全符合office标准，样式、内容控制非常便利，打印也不会变形，生成的文档和office中编辑文档完全一样。

总结

伴随着手机的兴起，不管是传统行业还是互联网行业对系统都有在移动端使用的要求，不管是从用户体验上还是从移动系统兼容性以及浏览器兼容性上都会遇到各种问题，当然也有工具可以解决这些问题，例如：RN、flutter都可以很好的解决系统兼容问题，vue.js、angularjs都可以很好的解决浏览器兼容问题，而且这些都有大厂的支持，关于以上的问题这种解决方法并不是最好的，但是可以做为一种参考，重点是对问题的总结，只要解决问题的方法符合自己的业务场景我个人认为就是正（有）确（效）的方法，如果有更好的方式可以在下放留言一起讨论。

使用a标签的download属性又有浏览器兼容问题，而且download属性有一个弊端，只有点击右键另存为才会生效，直接点击是不生效的。

因此我们这里借助了一个组件downloadjs来进行文件下载，它可以修改下载文件的名称，并且也没有浏览器兼容问题，原理呢很简单那，使用ajax请求去下载文件，在发起请求时构造请求header来重命名下载文件名。

但是这里会存在一个问题？我们的fastdfs和应用程序是独立的两个域，因此存在跨域的问题，直接使用a标签的href是不存在跨域的问题，按关于这个跨域的问题我们如何解决？

先来看一下使用downloadjs下载fastdfs的文件时报出的跨域错误信息如下

Failed to load http://192.168.0.48:8079/group1/M00/03/35/wKgAMFtgB2SAFjibAAX3egrfUI8922.doc: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8080' is therefore not allowed access.

本地使用是通过vue的proxyTable绕过跨域的问题，其实就是前端的proxy方式虚拟一个context然后pass转发，虽然这样可以解决目前的问题，但是我们在uat和prd环境又要增加相同的context path的映射，这不是我们想要的，我们想直接访问下载地址来进行下载，因此我们需要修改fastdfs的nginx模块配置。

跨域的配置这里就不多说了，其实就是添加一系列的Access-Control-Allow-X的header即可，不会的可以参考我以前的文章跨域踩坑经验总结》，唯一需要注意的是，当使用Access-Control-Allow-Credentials=true时Access-Control-Allow-Origin不允许使用* 必须使用具体的域名多个可以使用,分割。

修改后我们可以直接的请求地址下载文件即可。

代码示例

@Before
public void setUp() throws IOException {
    initMocks(this);
    final Random random = new SecureRandom();
    redisServer = new RedisServer();
    redisServer.start();
 
    pool = new JedisPool();
    repository = new RedisKeyRepository(pool);
    manager = new RedisKeyManager(random, pool, repository);
    manager.setMaxActiveKeys(3);
 
    clearData();
    manager.initialiseNewRepository();
 
    resource = new ProtectedResource(repository, random);
}

这是一个非常简单的使用示例，我们还可以更改配置以及增加密码

@Before
public void setUpRedis() throws IOException, SchedulerConfigException {
    port = getPort();
    logger.debug("Attempting to start embedded Redis server on port " + port);
    redisServer = RedisServer.builder()
            .port(port)
            .build();
    redisServer.start();
    final short database = 1;
    JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
    jedisPoolConfig.setTestOnBorrow(true);
    jedisPool = new JedisPool(jedisPoolConfig, host, port, Protocol.DEFAULT_TIMEOUT, null, database);
 
    jobStore = new RedisJobStore();
    jobStore.setHost(host);
    jobStore.setLockTimeout(2000);
    jobStore.setPort(port);
    jobStore.setInstanceId("testJobStore1");
    jobStore.setDatabase(database);
    mockScheduleSignaler = mock(SchedulerSignaler.class);
    jobStore.initialize(null, mockScheduleSignaler);
    schema = new RedisJobStoreSchema();
 
    jedis = jedisPool.getResource();
    jedis.flushDB();
}

使用RedisServerBuilder构建Redis server，并且指定port

@Test
//Note the try/finally is to ensure that the server is shutdown so other tests do not have to
//provide auth information
public void testAuth() throws Exception {
 
  RedisServer server = RedisServer.builder().port(6381).setting("requirepass foobar").build();
  server.start();
  RedisOptions job = new RedisOptions()
    .setHost("localhost")
    .setPort(6381);
  RedisClient rdx = RedisClient.create(vertx, job);
 
  rdx.auth("barfoo", reply -> {
    assertFalse(reply.succeeded());
    rdx.auth("foobar", reply2 -> {
      assertTrue(reply2.succeeded());
      try {
        server.stop();
      } catch (Exception ignore) {
      }
      testComplete();
    });
  });
  await();
}

设置一个需要密码访问的Redis server，setting可以设置redis conf中的所有属性

更多用法

还有很多用法，具体查看下面的代码示例

@Test
public void testDebugSegfault() throws Exception {
 
  RedisServer server = RedisServer.builder().port(6381).build();
  server.start();
  RedisOptions job = new RedisOptions()
    .setHost("localhost")
    .setPort(6381);
  RedisClient rdx = RedisClient.create(vertx, job);
 
  rdx.debugSegfault(reply -> {
    // this should fail, since we crashed the server on purpose
    assertTrue(reply.failed());
    rdx.info(reply2 -> {
      assertFalse(reply2.succeeded());
      server.stop();
      testComplete();
    });
  });
  await();
}

public RedisServerResource(int port, String password) {
    this.port = port;
    try {
        RedisExecProvider redisExecProvider = RedisExecProvider.defaultProvider();
        this.redisServer = RedisServer
                .builder()
                .redisExecProvider(redisExecProvider)
                .port(port)
                .setting("requirepass " + password)
                .build();
    } catch (Throwable error) {
        String message = String.format("failed creating Redis server (port=%d)", port);
        throw new RuntimeException(message, error);
    }
}

@Before
public void before() throws Exception {
  mockTracer.reset();
 
  redisServer = RedisServer.builder().setting("bind 127.0.0.1").build();
  redisServer.start();
} 

private void startServer(TestContext testContext) {
    EmbeddedRedis embeddedRedis = AnnotationUtils.findAnnotation(testContext.getTestClass(), EmbeddedRedis.class);
    int port = embeddedRedis.port();
 
    try {
        server = new RedisServer(port);
        server.start();
    } catch (IOException e) {
        if (logger.isErrorEnabled()) {
            logger.error(e.getMessage(), e);
        }
    }
}

private RedisServer createRedisServer() {
    final RedisServerBuilder redisServerBuilder = RedisServer.builder()
            .port(redisPort)
            .setting("appendonly yes")
            .setting("appendfsync everysec");
    settings.stream().forEach(s -> redisServerBuilder.setting(s));
 
    final RedisServer redisServer = redisServerBuilder.build();
    return redisServer;
}