业务场景
场景
提供Restful API接口直接读取Redis中的缓存数据，Redis的数据是通过MQ异步扔进去的。
目标
提供可靠的快速查询API服务，支持服务横向扩展。
指标
按照 500 个连接进行计算，服务器成本也是考量的一部分。暂时不考虑公网、带宽、网关的影响。
第一种技术
启动设置
/usr/bin/java -XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=256m -Xmx768m -Xms768m -XX:NewSize=1 -Xss256k -jar ps1.jar
压测结果
[root@tech-0001 wrk]# wrk -t4 -c500 -d60s 'http://127.0.0.1:9021/hotdog/redis?key=aaa' --latency -- / 16
Running 1m test @ http://127.0.0.1:9021/hotdog/redis?key=aaa
4 threads and 500 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 114.57ms 12.10ms 313.86ms 98.16%
Req/Sec 1.10k 88.43 1.26k 89.51%
Latency Distribution
50% 113.75ms
75% 115.66ms
90% 117.58ms
99% 134.86ms
262303 requests in 1.00m, 82.55MB read
Requests/sec: 4366.86
Transfer/sec: 1.37MB
第二种技术
启动配置
java -XX:MetaspaceSize=32m -XX:MaxMetaspaceSize=128m -Xmx256m -Xms256m -XX:NewSize=1 -Xss256k -jar ps2-fat.jar run com.tech.luckin.MainVerticle
压测结果
[root@jiaomatech-0001 wrk]# wrk -t4 -c500 -d60s 'http://127.0.0.1:8081/app/redis?key=aaa' --latency -- / 16
Running 1m test @ http://127.0.0.1:8081/app/redis?key=aaa
4 threads and 500 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 37.45ms 54.67ms 228.47ms 83.90%
Req/Sec 9.17k 4.36k 14.08k 72.72%
Latency Distribution
50% 10.12ms
75% 22.99ms
90% 140.38ms
99% 206.51ms
1959728 requests in 1.00m, 80.36MB read
Requests/sec: 32635.44
Transfer/sec: 1.34MB
存疑
稳定性
第一种技术的标准差很低，服务稳定性很高，第二种相对没有优势。
QPS
第二种技术的平均QPS达到 32635.44 Requests/sec。是第一种技术的7.5倍，没超过10倍，也算有不错优势。
平均响应
第二种技术的平均耗时37.45ms。而第二种的平均耗时是114.57ms，大约差3倍。
服务器成本
第二种技术的可以在低内存下提供不错的性能，而第一种技术在低内存下启动都存在问题。
然后
不同的场景下，每种技术框架的优缺点都有所不同，觉得异构框架是种不错的方案，让合适的工具做正确的事情。针对当前的场景，你会选择哪一种技术作为你的方案呢？
我想选第一种！！！
