数据库中有一个bigint类型数据，对应java后台类型为Long型，在某个查询页面中碰到了问题：页面上显示的数据和数据库中的数据不一致。例如数据库中存储的是：1475797674679549851，显示出来却成了1475797674679550000，后面几位全变成了0，精度丢失了。

上篇文章介绍了一个方法，解决了导出Excel过程中内存溢出的问题。但是有些问题还没有搞明白，那就是为什么要这样打开数据库游标？为什么fetchSize必须为：-2147483648？这里面涉及到数据库游标的更多信息，这一篇文章将深入介绍这方面内容。

在数据库中，游标是一个十分重要的概念。游标提供了一种对从表中检索出的数据进行操作的灵活手段，就本质而言，游标实际上是一种能从包括多条数据记录的结果集中每次提取一条记录的机制。游标总是与一条SQL 选择语句相关联因为游标由结果集（可以是零条、一条或由相关的选择语句检索出的多条记录）和结果集中指向特定记录的游标位置组成。

MySQL数据库游标通常有两种形式：Client Side Cursor（客户端游标）和Server Side Cursor（服务器端游标）。默认情况下，客户端游标会把整个结果集获取到客户端内存中，如果结果集太大，就会引发Out Of Memory错误；而服务器端游标会将结果集缓存在服务器端，客户端从服务器端分批获得结果集。

MySQL默认是使用客户端游标的，因为通常情况下，程序处理的结果集不会特别大，对小结果集使用客户端游标效率更高：结果集一次性传输到客户端，客户端可以自行处理，服务器端也可以为其他客户端提供服务。但是针对大结果集，默认的客户端游标处理方式满足不了要求，针对这种情况，MySQL的Java客户端做了一个特殊的处理。下面参照官方帮助看一下。

云认证平台提供将认证记录导出为Excel的功能。但是当业务量慢慢发展起来以后，就碰到一个比较棘手的问题：需要导出的认证记录太多，导出Excel的时候经常碰到服务器内存溢出问题。例如当要导出30w条记录的时候，服务端内存占用会超过2G，继续增加Heap空间不是一个非常合适的方案，因为无法预知一共需要多少内存。

因此，这两天特意找了一下解决方案，终于有了解决方案。最终方案导出256w条记录的时候，服务器内战占用1.6G，不再继续增加。

Spring项目中使用数据库的方式多种多样，注入MyBatis、JDBC、Hibernate等等都是支持的。之前的系统是基于MyBatis的。

关于如何Spring Boot和MyBatis网上有很多文章，可以参考。有时间我也会专门写一篇介绍集成的过程。本文讲的就是MyBatis移植到Spring Boot方面碰到的一些问题，主要是事务控制方面的。

相比于Spring来说，在SpringBoot中使用Redis大幅简化了。通过使用spring-boot-starter-data-redis，使用Redis变得非常简单。

基本步骤如下：

1. 添加依赖

1<dependency>
2    <groupId>org.springframework.boot</groupId>
3    <artifactId>spring-boot-starter-data-redis</artifactId>
4</dependency>

2. 配置application.properties/yaml

1spring:
2  redis:
3    host: 192.168.2.230
4    port: 6379
5    password: xxxxxx
6    database: 1
7    timeout: 3000ms

3. 注入RedisTemplate使用

1    @Autowired
2    StringRedisTemplate stringRedisTemplate;

就是这么简单。

原先云认证中有几个特殊加载的组件：

1. checkingServlet：一个Servlet，用于检查系统的状态，主要用于负载均衡LB检测服务是否正常使用。该Servlet定义了了一组URL，可以用来检查系统的状态，例如：/checking/database（检查数据库是否可以访问），/checking/version（返回系统版本号），/checking（总体检查系统状态）等。这些功能理论上不适用Servlet也能够实现，但是由于历史原因采用了Servlet，这次一直也不考虑重新编写。
2. ClientCertificateFromProxyFilter：一个Filter，用于检查负载均衡转发过来的客户端证书，配合Spring Security完成双向SSL的认证工作。

首先说一下背景信息。云认证平台是一个传统的Spring项目，从上到下可以分为：API层（对应Spring Controller）、Service层、DAO层（MyBatis）几层。为了方便处理，从开发规范上我们要求了Service层的异常在Service层自行处理。

为了实现这一点，在接口定义上，从API层调用Service层的请求会有统一的返回基类：CommonResult。其定义如下：

 1public class CommonResult implements Serializable {
 2    private static final long serialVersionUID = 1L;
 3
 4    /**
 5     * success 请求成功与否的标志。
 6     */
 7    protected boolean success = Boolean.FALSE;
 8    /**
 9     * resultCode 返回码。
10     */
11    protected String resultCode = "";
12    /**
13     * message 详细信息。
14     */
15    protected String message = "";
16    ...
17}

所有需要从API层调用到的Service层的返回值都是该类或者该类的子类。如果是Service层之间互相调用，则不受此限制。

本章的内容主要与AOP有关。

首先简单说一下云平台的业务功能：云平台上提供了多种多样的服务，这些服务可能来源于不同的供应商。也就是说对于某一种服务来说，可能会有多个供应商提供相同的服务；而对于某一个供应商来说，它可能提供多种服务。

之前的云平台中有一个插件机制，使用插件机制解决了供应商与系统的耦合度问题。系统抽象了服务层，服务层在合适的时机加载插件以调用供应商的服务。

加载相关的代码大概类似这样：

 1...
 2ClassLoader localClassLoader = Thread.currentThread().getContextClassLoader();
 3for (String str : providerClassNames) {
 4    try {
 5        Class<?> localClass = localClassLoader.loadClass(str);
 6        XXXServiceProvider localProvider = (XXXServiceProvider) localClass.newInstance();
 7        localProvider.initial();// 初始化插件
 8    } catch (Exception e) {
 9		...
10    }
11}
12...

providerClassNames是一个数组，其中并所有插件的主类名字。通过获取到的ClassLoader，对插件主类进行加载，从而获得插件对象。

最近因为发布方面的原因，需要对项目进行一次改造，趁着这次机会，对云平台项目进行了彻底的重构，迁移到了Spring Boot上。改造过程中，从传统的Spring项目迁移到Spring Boot上，还是碰到了一些问题的，也因此留下了这个系列的笔记。其中的内容，应该对希望把传统的Spring项目迁移到Spring Boot的人会有所帮助。

HttpClient是Apache Jakarta Common下的子项目，用来提供高效的、最新的、功能丰富的支持HTTP协议的客户端编程工具包，并且它支持HTTP协议最新的版本和建议。HttpClient已经应用在很多的项目中，比如Apache Jakarta上很著名的另外两个开源项目Cactus和HTMLUnit都使用了HttpClient。

目前最新的版本是4.5，支持HTTP 1.0/HTTP 1.1协议。正在开发中的5.0版本（还在Beta阶段）支持HTTP/2协议。

1. 特性

1. 基于标准、纯净的java语言。实现了Http1.0和Http1.1
2. 以可扩展的面向对象的结构实现了Http全部的方法（GET, POST, PUT, DELETE, HEAD, OPTIONS, and TRACE）。
3. 支持HTTPS协议。
4. 通过Http代理建立透明的连接。
5. 利用CONNECT方法通过Http代理建立隧道的https连接。
6. Basic, Digest, NTLMv1, NTLMv2, NTLM2 Session, SNPNEGO/Kerberos认证方案。
7. 插件式的自定义认证方案。
8. 便携可靠的套接字工厂使它更容易的使用第三方解决方案。
9. 连接管理器支持多线程应用。支持设置最大连接数，同时支持设置每个主机的最大连接数，发现并关闭过期的连接。
10. 自动处理Set-Cookie中的Cookie。
11. 插件式的自定义Cookie策略。
12. Request的输出流可以避免流中内容直接缓冲到socket服务器。
13. Response的输入流可以有效的从socket服务器直接读取相应内容。
14. 在http1.0和http1.1中利用KeepAlive保持持久连接。
15. 直接获取服务器发送的response code和 headers。
16. 设置连接超时的能力。
17. 实验性的支持http1.1 response caching。
18. 源代码基于Apache License 可免费获取。