平常積累

1      樂觀鎖實例：

假設數據庫中賬戶信息表中有一個version字段，當前值爲1;而當前賬戶餘額字段(balance)爲$100。下面咱們將用時序表的方式來爲你們演示樂觀鎖的實現原理：

操做員A	操做員B
(1)、操做員A此時將用戶信息讀出（此時version=1），並準備從其賬戶餘額中扣除$50（$100-$50）	(2)、在操做員A操做的過程當中，操做員B也讀入此用戶信息（此時version=1），並準備從其賬戶餘額中扣除$20（$100-$20）
(3)、操做員A完成了修改工做，將數據版本號加1（此時version=2），連同賬戶扣除後餘額（balance=$50），提交至數據庫更新，此時因爲提交數據版本大於數據庫記錄當前版本，數據被更新，數據庫記錄version更新爲2
	(4)、操做員B完成了操做，也將版本號加1（version=2）並試圖向數據庫提交數據（balance=$80），但此時比對數據庫記錄版本時發現，操做員B提交的數據版本號爲2，數據庫記錄當前版本也爲2，不知足「提交版本必須大於記錄當前版本才能執行更新」的樂觀鎖策略，所以，操做員B的提交被駁回

這樣，就避免了操做員B用基於version=1的舊數據修改的結果來覆蓋操做員A的操做結果的可能。

2      Java的併發包提供了三個經常使用的併發隊列實現，分別是：ConcurrentLinkedQueue 、 LinkedBlockingQueue 和 ArrayBlockingQueue。

ArrayBlockingQueue是初始容量固定的阻塞隊列，咱們能夠用來做爲數據庫模塊成功競拍的隊列，好比有10個商品，那麼咱們就設定一個10大小的數組隊列。

ConcurrentLinkedQueue使用的是CAS原語無鎖隊列實現，是一個異步隊列，入隊的速度很快，出隊進行了加鎖，性能稍慢。

LinkedBlockingQueue也是阻塞的隊列，入隊和出隊都用了加鎖，當隊空的時候線程會暫時阻塞。

3      DNSPOD：DNSPod是中國第一大DNS解析服務提供商、第一大域名託管商。

它除了實時生效、不限制用戶添加的域名和記錄數量、提供URL轉發、搜索引擎優化、域名共享管理、域名鎖定、IPv6的支持、動態域名解析、API接口、批量修改管理等先進功能外，還擁有：雲DNS、DNSPod DNS Protector（DNSPod 自主研發的DNS 防禦軟件）、宕機監控、安全中心、7*24小時專業技術支持。而且全部功能都是免費向全部用戶提供。

4      高併發網站設計要點

獨立部署；

頁面靜態化並上CDN；

作（uid+timeout）頁面緩存，限制同一個UID的訪問頻率；

作（args+timeout）頁面緩存，一樣參數的請求限制訪問頻率；

寫請求加入隊列，讀請求cache來抗；

過載保護；

5      數據庫設計

5.1      MongoDB查詢：

海量數據分頁查詢：

db.message_test.aggregate([{ $match: { server: "w00172255-1215:1027(taskId:4" } },{ $sort : { _id: 1 } },{ $skip: 200000 },{ $limit: 20 }],{allowDiskUse: true})

skip最好改爲排序條件>當前最大值的方式

5.2      高性能設計

數據可用性：冗餘數據；

提升數據庫讀性能（大部分應用讀多寫少，讀會先成爲瓶頸）：索引，讀寫分離；

保證一致性：中間件，緩存+緩存淘汰設計（寫庫先淘汰緩存，再寫，再通過主從同步延時經驗時間後異步再次淘汰cache）；

提升擴展性：分表分庫；

1  標籤系統通常會這麼設計：  

根  

--分類1  

----子分類1  

------標籤1 標籤2 標籤3  

--分類2  

----子分類2 

------標籤4 標籤5 標籤6  

對於豆瓣多是：  

根  

--讀書  

----文學  

------小說 隨筆 散文  

--電影

----類型  

------愛情 喜劇 動畫  

----國家 

------美國 中國 香港  

我以爲：  

1.豆瓣的書、電影和音樂可能會打上分類（分類也是標籤），但沒有打上子分類，而是直接打了標籤。  

2.大部分的標籤都是用戶本身打上去的，這是一個很重要的標籤來源。  

3.算法產生的標籤，可能跟用戶的喜愛比較貼近。好比我常常看計算機書籍，本身也打了不少這方面的標籤，好比java/linux/分佈式。那麼我這個用戶在豆瓣中的喜愛分類（算法產生），可能會是IT，那麼IT相關的書籍，都會推薦給我。  

4.算法是怎麼產生標籤的？用戶本身打標籤的處理，用戶瀏覽某些頁面的日誌處理，用戶請求某些接口的日誌處理。好比我常常瀏覽《三個傻瓜》的影評、圖片，那麼算法會認爲我喜歡印度片，給我打上寶萊塢的標籤也說不定。 

以上都是推測的，助於理解。

6      nginx配置

nginx_tcp_proxy_module——實現tcp代理

nginx_upstream_check_module——監控後端服務器，在服務器失效時移除失效upstream

nginx_upstream_jvm_route——基於 Cookie 的 Session Sticky 的功能，推薦使用（儘可能不要用ip_hash：1/ nginx不是最前端的服務器。

   ip_hash要求nginx必定是最前端的服務器，不然nginx得不到正確ip，就不能根據ip做hash。譬如使用的是squid爲最前端，那麼nginx取ip時只能獲得squid的服務器ip地址，用這個地址來做分流是確定錯亂的。

    2/ nginx的後端還有其它方式的負載均衡。

   假如nginx後端又有其它負載均衡，將請求又經過另外的方式分流了，那麼某個客戶端的請求確定不能定位到同一臺session應用服務器上。

   3/ 多個外網出口。

    不少公司上網有多個出口，多個ip地址，用戶訪問互聯網時候自動切換ip。並且這種狀況不在少數。使用 ip_hash 的話對這種狀況的用戶無效，沒法將某個用戶綁定在固定的tomcat上 。）