摘要： 有四種： 第一種AbortPolicy:不執行新任務，直接拋出異常，提示線程池已滿 第二種DisCardPolicy:不執行新任務，也不拋出異常 第三種DisCardOldSetPolicy:將消息隊列中的第一個任務替換為當前新進來的任務執行 第四種CallerRunsPolicy:直接調用exec 閱讀全文

摘要： CachedThreadPool:可緩存的線程池，該線程池中沒有核心線程，非核心線程的數量為Integer.max_value，就是無限大，當有需要時創建線程來執行任務，沒有需要時回收線程，適用于耗時少，任務量大的情況。 SecudleThreadPool:周期性執行任務的線程池，按照某種特定的計劃 閱讀全文

摘要： http中的post請求發生了兩次（多了一次options請求）的原因 兩次請求一般：第一條為options請求，第二條請求才是我們預想中的請求。為什么先發起了一條options請求： options請求 options請求的官方定義：OPTIONS方法是用于請求獲得由Request-URI標識的資 閱讀全文

摘要： 緩存雪崩 緩存雪崩指的是緩存同一時間大面積的失效，所以，后面的請求都會落到數據庫上，造成數據庫短時間 內承受大量請求而崩掉。 解決辦法 事前：盡量保證整個 Redis 集群的高可用性，發現機器宕機盡快補上，選擇合適的內存淘汰策略。 事中：本地ehcache緩存 + hystrix限流&降級，避免My 閱讀全文

摘要： 一、緩存雙淘汰法 1. 先淘汰緩存 2. 再寫數據庫 3. 往消息總線esb發送一個淘汰消息，發送立即返回。寫請求的處理時間幾乎沒有增加，這個方法淘汰 了緩存兩次。因此被稱為“緩存雙淘汰法“，而在消息總線下游，有一個異步淘汰緩存的消費者，在拿 到淘汰消息在1s后淘汰緩存，這樣，即使在一秒內有臟數據入 閱讀全文

摘要： 這樣的問題主要是在并發讀寫訪問的時候，緩存和數據相互交叉執行。 一、單庫情況下 同一時刻發生了并發讀寫請求，例如為A(寫) B (讀)2個請求 1. A請求發送一個寫操作到服務端，第一步會淘汰cache，然后因為各種原因卡主了，不在執行后面業務 (例：大量的業務操作、調用其他服務處理消耗了1s）。 閱讀全文

摘要： 首先說一句，你只要用緩存，就可能會涉及到緩存與數據庫雙存儲雙寫，你只要是雙寫，就一定會有數 據一致性的問題，那么你如 何解決一致性問題？ 一般來說，就是如果你的系統不是嚴格要求緩存+數據庫必須一致性的話，緩存可以稍微的跟數據庫偶 爾有不一致的 情況，最好不要做這個方案，最好將讀請求和寫請求串行化，串 閱讀全文

摘要： 所謂 Redis 的并發競爭 Key 的問題也就是多個系統同時對一個 key 進行操作，但是最后執行的順序和我 們期望的順序不同，這樣也就導致了結果的不同！ 推薦一種方案：分布式鎖（zookeeper 和 Redis 都可以實現分布式鎖）。（如果不存在 Redis 的并發競爭 Key 問 題，不要使 閱讀全文

摘要： Redis Sentinel（哨兵）著眼于高可用，在master宕機時會自動將slave提升為master，繼續提供服務。 Sentinel（哨兵）可以監聽集群中的服務器，并在主服務器進入下線狀態時，自動從服務器中選舉出新的主服務器。 Redis Cluster（集群）著眼于擴展性，在單個Redis 閱讀全文

摘要： AOF重寫可以產生一個新的AOF文件，這個新的AOF文件和原有的AOF文件所保存的數據庫狀態一樣， 但體積更小。 AOF重寫是一個有歧義的名字，該功能是通過讀取數據庫中的鍵值對來實現的，程序無須對現有AOF文 件進行任伺讀 入、分析或者寫入操作。 在執行 BGREWRITEAOF 命令時，Redis 閱讀全文