序言
現在在技術選型,尤其關注軟件的能夠提供的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會報錯,