序言
现在在技术选型,尤其关注软件的能够提供的QPS,当然这也是必然的.所以整理下不同服务之间的应用级别
QPS
QPS(是每秒查询率) = 并发数 / 平均响应时间
例如:
- 如果一次性可以处理100个请求，每个请求耗时100毫秒，则qps = 1000
- 如果一次性可以处理50个请求，每个请求耗时200毫秒，则qps = 250
峰值QPS
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器
问：每天300w PV 的在单台机器上，这台机器需要多少QPS？
答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
问：如果一台机器的QPS是58，需要几台机器来支持？
答：139 / 58 = 3
MQ服务
Kafka是高吞吐低延迟的高并发、高性能的消息中间件，在大数据领域有极为广泛的运用。配置良好的Kafka集群甚至可以做到每秒几十万、上百万的超高并发写入。
一般RabbitMQ的单机QPS在万级别之内，而Kafka的单机QPS可以维持在十万级别，甚至可以达到百万级。
很明显的看出kafka的性能远超rabbitmq。不过这也是理所当然的，毕竟2个消息队列实现的协议是不一样的，处理消息的场景也大有不同。rabbitmq适合处理一些数据严谨的消息，比如说支付消息，社交消息等不能丢失的数据。kafka是批量操作切不报证数据是否能完整的到达消费者端，所以适合一些大量的营销消息的场景。
NoSql数据库
redis单机的话能够提供5w左右的QPS,如果是服务器读写分离可以提供到10w. 关于redis-cluster 集群如果机器太多了会增加沟通交互的成本,所以集群的百万左右差不多可以了.Redis为内存型KV系统，处理的数据量要小于HBase与MongoDB
HBase基于列存储，提供<key, family:qualifier, timestamp>三项座标方式定位数据，由于其qualifier的动态可扩展型（无需schema设计，可存储任意多的qualifier），特别适合存储稀疏表结构的数据（比如互联网网页类）。HBase不支持二级索引，读取数据方面只支持通过key或者key范围读取，或者全表扫描。
MongoDb在类SQL语句操作方面目前比HBase具备更多一些优势，有二级索引，支持相比于HBase更复杂的集合查找等。BSON的数据结构使得处理文档型数据更为直接。MongoDb也支持mapreduce，但由于HBase跟Hadoop的结合更为紧密，Mongo在数据分片等mapreduce必须的属性上不如HBase这么直接，需要额外处理。
HBase与Mongodb的读写性能正好相反，HBase写优于随机读，MongoDB似乎写性能不如读性能。
| 扩展性 | 表设计 | 负载均衡 | failover | 事务 | 适用数据量 | |
|---|---|---|---|---|---|---|
| RDBMS | 差 | 灵活性较弱 | 差 | 同步实现 | 支持 | 万级 |
| HBase | 强 | 十亿级行，百万级列;动态列，每行列可不同。且引入列族和数据多版本概念。 | 强 | 各组件都支持HA | MVCC, Produce LOCK;行级事务 | 亿级 |
ORM
从 iBatis 到 MyBatis，不只是名称上的变化，MyBatis 提供了更为强大的功能，同时并没有损失其易用性，相反，在很多地方都借助于 JDK 的泛型和注解特性进行了简化.
在 iBatis 中，namespace 不是必需的，且它的存在没有实际的意义。在 MyBatis 中，namespace 终于派上用场了，它使得映射文件与接口绑定变得非常自然。MyBatis中一条sql结束后可以有“;”，而iBatis会报错,