手机号登录接口：
连接池设置：最小20连接，最大80连接
Jmeter设置：持续三分钟
纯DB：
任务：测试dubbo1000线程和dubbo1500线程的不同表现
200线程+dubbo1000线程：压测3分钟
异常率达到0.13%，大概是从第1分钟开始陆续出现异常
主要的异常原因：超时
400线程+dubbo1000线程：
异常率0.13%，其实还可以接受
主要原因：超时
600线程+dubbo1000线程：
异常率：0.13%
主要原因：超时
800线程+dubbo1000线程：
异常率：0.07%
主要原因：超时
1000线程+dubbo1000线程：
异常率：0.13%
主要原因：超时并且出现小部分拒绝服务
1100线程+dubbo1000线程：
服务完全不可用
异常率：94%
主要原因：超时、并且dubbo直接拒绝任务（50051 直接快速拒绝连接），因为允许的最大线程数量是1000
1100线程++dubbo1500线程：
还行，能接受
异常率：0.1%
主要原因：超时
1300线程+dubbo1500线程：
同样可以接受
异常率：0.13%
主要原因：超时以及少量dubbo拒绝任务
1500线程+dubbo1500线程：
异常率：0.11%
主要原因：超时以及dubbo拒绝任务
总结：
- dubbo1000线程情况下，服务的极限是1000线程，异常率和吞吐量都还可以接受，但是平均响应时间太长了
- dubbo1500线程情况下，服务的极限状态是1300线程，异常率和吞吐量都还可以接受，但是平均响应时间太长了
DB+redis缓存+布隆过滤器：
主要测试：（数据已经提前预热到redis缓存中）
dubbo1000线程情况下，Jmeter 1000线程情况下会有什么表现
dubbo1500线程情况下，Jmeter 1300线程情况下会有什么表现
dubbo1500线程情况下，Jmeter 1500线程情况下会有什么表现
1000线程+dubbo1000线程：
这个基本已经达到生产级的要求了，整体的吞吐量和响应时间都很优秀
异常率：0.04%
主要原因：基本没有看到超时的字眼，更多是因为被拒绝服务，因为dubbo最大允许1000个线程，可能恰好卡掉几个
1300线程+dubbo1500线程：
这个同样可以
异常率0%
1500线程+dubbo1500线程：
异常率：0.05%
主要原因：任务太多，被拒绝服务
1600线程+dubbo1500线程：
异常率：40.65%
主要原因：任务太多，被拒绝服务
可以对比发现，当线程数量超过dubbo的最大允许线程数量时，会被大量拒绝，造成服务雪崩
此外就是在1000线程+dubbo1000线程情况下，加redis之后，异常率从1.54%降低到0.04%，吞吐量从37.2提升到9301.4，平均响应时间从22946降低到105
在1300线程+dubbo1500线程情况下，加redis之后异常率直接从2.06%降低到0，吞吐量从29.1提升到9411.9，平均响应时间从39149降低到135
查询用户信息接口
纯DB
800线程+dubbo1000线程：
异常率：7.78%
主要原因：连接超时，服务超时，并且部分服务被拒绝
已经到服务的极限了
1000线程+dubbo1500线程：
也是差不多到极限了
异常率：7.81%
主要原因：连接超时，服务超时，并且部分服务被拒绝
DB+redis缓存+布隆过滤器：
主要测试：
800线程+dubbo1000线程和1000线程+dubbo1500线程
800线程+dubbo1000线程：
异常率为0
1000线程+dubbo1500线程：
异常率0%
可以看到使用了redis，吞吐量和异常率以及平均响应时间都有很大的进步
