短信中间件核心在于中间层，把复杂的底层操作转换为简单、方便的数据库操作。软件设计为从客户的数据库自动定时提取数据发送。中间件需要和用户的应用程序共享使用数据库，这就要求中间件访问数据库既要快，又不能影响数据库的性能。数据库连接池是必不可少的。

数据库连接池就是一个池子，里面放着数据库连接，应用服务需要的时候就去池子里面拿，用完之后归还给池子。数据库连接池负责分配、管理、释放数据库连接，它允许应用服务重复使用数据库连接，而非重新建立。数据库的连接创建和关闭连接均由连接池来实现。应用访问时，首先查看连接池中是否有空闲连接，如果存在空闲连接，则将连接分配给客户使用；如果没有空闲连接，则查看当前所开的连接数是否已经达到最大连接数，如果没达到就重新创建一个连接给请求的客户；如果达到就按设定的最大等待时间进行等待，如果超出最大等待时间，则抛出异常给客户。 当客户释放数据库连接时，先判断该连接的引用次数是否超过了规定值，如果超过就从连接池中删除该连接，否则保留等待再次使用。

如果不使用数据库连接池，进行一次查询，要进行很多次网络交互，可以看到，这样的缺点是：

1. 网络IO多

2. 响应时间长，导致QPS降低

3. 频繁创建连接和关闭连接，浪费数据库资源，影响服务器性能

使用连接池的好处：

1. 减少网络开销

2. 提升数据库性能

金笛短信中间件对连接池有2个要求：一要快，二要稳。目前，流行的Java数据库连接池有dbcp，druid，HikariCP，tomcat-jdbc，c3p0。在对所有流行的连接池进行逐一比较之后，单从性能角度看，性能从高到低分别是：HikariCP，druid，tomcat-jdbc，dbcp，c3p0 。

关于HikariCP和druid的性能对比，在github/HikariCP上有过讨论，结果是HikariCP性能上优于druid，吃瓜地址：https://github.com/brettwooldridge/HikariCP/issues/232

HikariCP 脱颖而出，符合金笛短信中间件短信要求既要快，又要稳的要求。短信从提取到发送，在数据库这个环节，把时间压缩到毫秒内，只有短信发送的每个环节都榨干，才能保证最终短信发送秒到。

各种评测对比，也说明HikariCP是目前最快的Java数据库连接池，spring boot 2.x已经使用HikariCP作为默认的数据库连接池，足见其优秀。总代码量：代码体积更是少的可怜，130kb。代码量越少，一般意味着执行效率越高、发生bug的可能性越低。简单意味着可靠，好维护，兼容性好。

数据库连接池，在20年以前就有。经过20年的进化，已经非常犀利。日本人素来以工匠精神著称，一个人一辈子就做好一件事。HikariCP是日本人在boneCP基础上，把优化做到了极致：为什么这么说呢?

1. 优化并精简字节码，优化代码，直到编译后的字节码最少，这样，CPU缓存可以加载更多的程序代码。使用Java字节码修改类库Javassist来生成委托实现动态代理，JDK Proxy生成的字节码更少。例如HikariCP的Statement proxy只有100行代码，只有BoneCP的十分之一，对编译器不满意，就差重写java编译器了。

2. 定义集合类型（ConcurrentBag）：提高并发读写的效率。

3. 自定义数组类型（FastStatementList）代替ArrayList：避免每次get()调用都要进行range check，避免调用remove()时的从头到尾的扫描。

4. 其他针对BoneCP缺陷的优化，比如对于耗时超过一个CPU时间片的优化。

光速，每秒30万公里。没有比光速更快的了。HikariCP ，就是光速。

本着geek精神，在可靠性方面，继续研究。对于数据库连接中断的情况，通过测试getConnection()，各种CP的不相同处理方法如下：

（所有CP都配置了跟connectionTimeout类似的参数为5秒钟）

HikariCP：等待5秒钟后，如果连接还是没有恢复，则抛出一个SQLExceptions 异常；后续的getConnection()也是一样处理；

C3P0：完全没有反应，没有提示，也不会在“CheckoutTimeout”配置的时长超时后有任何通知给调用者；然后等待2分钟后终于醒来了，返回一个error；

Tomcat：返回一个connection，然后……调用者如果利用这个无效的connection执行SQL语句……结果可想而知；大约55秒之后终于醒来了，这时候的getConnection()终于可以返回一个error，但没有等待参数配置的5秒钟，而是立即返回error；

BoneCP：跟Tomcat的处理方法一样；也是大约55秒之后才醒来，有了正常的反应，并且终于会等待5秒钟之后返回error了；

也就是在数据库连接中断的情况下，HikariCP在5秒内就可以感知，并在最短时间内通知上层应用。这个响应够快，够及时。实际测试中，就是拔网线，等半分钟再插上，看谁最先恢复数据库连接。HikariCP 又胜出。

金笛短信中间件WEB版集成光速数据库连接池，在各种数据库环境下表现异常稳定。有的客户在局域网连接阿里云主机数据库因为不明原因，间歇性断网的情况，也没有影响短信发送。实测支持SQLServer、Oracle、MySQL，支持win和linux各个版本。

金笛4G全网通短信一体机是一款真正的全网通，支持七模十八频段，真正可以做到任何SIM卡盲插，全网通，通全网。这七模十八频段罗列如下：

七模：

GSM：850/900/1800/1900（移动和联通的2G，即B2 B3 B5 B8）

CDMA：800（电信2G，即BC0）

WCDMA：2100/1900/850/900（联通3G，即B1 B2 B5 B8）

TD-SCDMA:1880-1920/2010-2025（移动3G，即B34 B39）

CDMA：1920-1935/2110-2125（电信3G，即BC1）

TDD-LTE：1900/2300/2600（移动4G，即B38 B39 B40 B41）

FDD-LTE：1800/2600（联通和电信的4G，即B1 B3 B7）

金笛MN1604产品照片

MN1604-5G左侧面

MN1604-5G右侧面

MN1604-5G左45°

金笛4G全网通短信一体机NM1604有两颗强劲的CPU，一颗是负责操作系统和网络，一颗负责短信。用一颗CPU负责短信，可见金笛对短信的重视程度。正是这块专用于发送短信的CPU，可以让短信发送速度达到3000条/小时，在网络比较好的情况下，甚至可以达到1秒1条。为了避免运营商对卡做限制，正常发送最好控制到1800条/小时以下。另外一颗CPU负责嵌入式操作系统和网络，在高速SD卡上存放有数据库和短信WEB服务，可以接入内网或者互联网，数据库可以使用内嵌的数据库，也可以通过JDBC连接用户自己的数据库。

NM1604除了可以使用自带的一个硬件SIM卡端口发送短信外，还支持通过手机APP和短信网关发短信。手机APP是在android手机上装一个APP软件，在APP里设定一体机的IP地址和端口号，可以直接连到数据库里定时抓取短信发送，并把发送结果填回数据库。网络发送是通过互联网连接到金笛短信平台，用户可以申请开通帐号，通过支付宝付款购买短信发送，支付宝充值成功后，短信条数自动充值到帐号里，操作起来都是自动化完成的，不需要人工干预。

NM1604支持市面上所有主流的数据库，包括国产数据库，通过JDBC实现跨网络、跨服务器连接异地数据库服务器。各种数据库的JDBC驱动都已经内嵌，无需手工配置。有的客户把NM1604部署到办公网络，通过互联网连接阿里云主机数据库服务器，也没有任何问题。NM1604内嵌光速数据库连接池，在网络出现异常时，可以不断尝试重新建立连接，直到网络恢复，所以不用担心断网，断网也会自动恢复，无需人工干预。设计的目的，就是一切自动化，智能化。

NM1604对于虚拟化环境尤其适合。虚拟化环境下，没法直接使用串口、USB口，可以通过IP地址连接短信一体机，建立通讯联系。NM1604是定时轮询数据库抓取数据发送，公有云、私有云、专有云、VMware等环境下，只要能和数据库建立连接就能发送，可以放在机房内，也可以放在机房外，哪里有信号就放哪里，部署起来非常灵活。

除了数据库接口外，NM1604还支持HTTP接口。这种方式是把一体机当成一个http server来使用，通过GET或者POST方式提交短信，获取发送结果，多个系统可以共享短信服务。

如果想收到短信后，立即做出响应，还可以通过回调功能执行用户自定义的工作，这时候一体机工作模式相当于http client，请求用户的URL。

失败重发机制，在发送失败后，可以根据预设的重发次数进行重发。对于CMS ERROR 512、CMS ERROR 515等运营商返回的错误系统会自动进行重发。

看门狗机制，每隔1分钟左右，会自动发送AT指令，如果能正常返回OK，如果连续几次不能正常返回OK，会自动重启短信发送端口。看门狗在系统可靠性方面也是一个有效的机制。

NM1604支持UCS2、7bit、8bit三种编码格式。UCS2就是普通的手机短信，可以是中文、日文韩文等双字节编码；7bit是发送英文短信；8bit是发送字节流，可以传输用户自定义的数据格式。

金笛短信一体机，集4G通讯技术和通信技术于一身，安全、可靠、方便，是网管类软件和各类业务系统触达用户手机，实现告警、通知、提醒功能的不二之选。