快取一致性問題
1：快取系統與底層資料的一致性。這點在底層系統是「可讀可寫」時，寫得尤為重要
2：有繼承關係的快取之間的一致性。為了盡量提高快取命中率，快取也是分層：全域性快取，二級快取。他們是存在繼承關係的。全域性快取可以有二級快取來組成。
3：多個快取副本之間的一致性。為了保證系統的高可用性，快取系統背後往往會接兩套儲存系統（如memcache，redis等）
快取穿透和快取雪崩
上面有講過
快取資料的淘汰
快取淘汰的策略有兩種：
(1) 定時去清理過期的快取。
(2)當有使用者請求過來時，再判斷這個請求所用到的快取是否過期，過期的話就去底層系統得到新資料並更新快取。
兩者各有優劣，第一種的缺點是維護大量快取的key是比較麻煩的，第二種的缺點就是每次使用者請求過來都要判斷快取失效，邏輯相對比較複雜，具體用哪種方案，大家可以根據自己的應用場景來權衡。
1. 預估失效時間
2. 版本號（必須單調遞增，時間戳是最好的選擇）
3. 提供手動清理快取的介面。
jbpm4工作流引擎描述
jpbm是jboss旗下的乙個開源的基於hibernate的工作流引擎。工作流就是在日常生活中，我們一些常見的如請假流程、採購流程、入職流程，通俗的來講就是一些在現實生活中的流程以資訊化以程式的方式實現。
乙個工作流首先需要進行流程定義，流程定義是由節點和跳轉組成的，節點又可以稱為環節、活動節點、活動環節，並且節點也可以分為兩大型別：人工節點和自動節點，人工節點有start開始節點、end結束節點、task任務節點，自動節點有decision判斷節點、fork分支節點、join聚合節點和state狀態節點，並且乙個流程有且只有乙個開始節點，但可以有多個結束節點。
流程定義是靜止的，它在執行狀態時會轉換成流程例項，乙個流程定義可以對應多個流程例項。流程執行後，會產生兩個檔案，*.jdpl.xml檔案和*.png檔案，也會生成18張資料庫表，常用且核心的表有jbpm4_lob 儲存表，主要儲存xml檔案和png、jbpm4_task 任務表、jbpm4_execution 流程例項表、jbpm4_variable變數表。
jbpm有五大核心類：
processengine：主要獲取各種的service
repositoryservice：主要發布流程定義
executionservice：主要操作流程例項
taskservice：主要操作人工服務
historyservice：主要操作歷史服務。
核心方法：
讀取jbpm定義的檔案生成zip包存到lob表中：createdeployment()
獲取流程定義列表：createprocessdefinitionquery
根據定義的key或id來啟動流程例項：startprocessinstancebykey(id)
獲取待辦任務列表：findpersonaltasks(username)
完成指定任務列表：completetask(*.getactivityid())
獲取歷史任務列表：createhistorytaskquery()
獲取流程例項的id：task.getexecutionid()
(了解的表)
jbpm4_hist_actinst 流程活動(節點) 例項表
jbpm4_hist_detail 流程歷史詳細表
jbpm4_hist_procinst 流程例項歷史表
jbpm4_hist_task 流程任務例項歷史表
jbpm4_hist_var 流程變數( 上下文) 歷史表
memcache的分布式快取問題
有關使用memcache做分布式快取的方案，簡單寫下來，僅供參考。memcache是優異的快取解決方案，很多專案都有使用。memcache服務本身並不具備分布式快取的能力，它提供的就是對對的訪問能力，分布式的能力則完全來自於客戶端。現在有不少memcache的客戶端lib採用consistent h...
memcache的分布式快取問題
memcache的分布式快取問題 memcache是優異的快取解決方案，很多專案都有使用。memcache服務本身並不具備分布式快取的能力，它提供的就是對對的訪問能力，分布式的能力則完全來自於客戶端。基於consistent hashing演算法的分布式快取 現在有不少memcache的客戶端lib...
分布式快取
分布式快取 原則來說跟應用伺服器分布式應該是一樣，但快取是有狀態的。怎麼樣提高命中？1.最原始的演算法 那就是key hash取模，取到伺服器ip。在大量伺服器伸縮行有問題，加入一台伺服器就有可能讓所有的快取都失效。如 key hash 後是100，取10膜是0，取11膜 1，101 取10膜是1，...