⑴ redis和mysql在處理高並發問題時有什麼差異
我的理解：
1、mysql支持sql查詢，可以實現一些關聯的查詢以及統計；
2、redis對內存要求比較高，在有限的條件下不能把所有數據都放在redis；
3、mysql偏向於存數據，redis偏向於快速取數據，但redis查詢復雜的表關系時不如mysql，所以可以把熱門的數據放redis，mysql存基本數據
看項目用在哪個地方吧，根據各自的所長結合起來才好用。
⑵ mysql 查詢後更新 高並發
一種：使用行鎖，SELECT `id` FROM `urls` ORDER BY `c_time` LIMIT 1 FOR UPDATE
壞處：進程阻塞
另外一種，使用更新隊列（添加一張記錄更新的時間隊列表，執行更新前，去隊列里查詢最新的更新時間，所有針對這個id的訪問都先把時間插入到時間隊列表），隊列可使用庫，也可以使用緩存（redis等）
⑶ RateLimiter令牌桶演算法淺析
網路中的定義：
令牌桶演算法是網路流量（Traffic Shaping）整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一種演算法。典型情況下，令牌桶演算法用來控制發送到網路上的數據的數目，並允許突發數據的發送。
大小固定的令牌桶可自行以恆定的速率源源不斷地產生令牌。如果令牌不被消耗，或者被消耗的速度小於產生的速度，令牌就會不斷地增多，直到把桶填滿。後面再產生的令牌就會從桶中溢出。最後桶中可以保存的最大令牌數永遠不會超過桶的大小。
傳送到令牌桶的數據包需要消耗令牌。不同大小的數據包，消耗的令牌數量不一樣。令牌桶這種控制機制基於令牌桶中是否存在令牌來指示什麼時候可以發送流量。令牌桶中的每一個令牌都代表一個位元組。如果令牌桶中存在令牌，則允許發送流量；而如果令牌桶中不存在令牌，則不允許發送流量。因此，如果突發門限被合理地配置並且令牌桶中有足夠的令牌，那麼流量就可以以峰值速率發送。
令牌桶演算法的基本過程：
假如用戶配置的平均發送速率為r，則每隔1/r秒一個令牌被加入到桶中；桶最多可以存發b個令牌。如果令牌到達時令牌桶已滿，則這個令牌會被丟棄；
當一個n個位元組的數據包到達時，就從令牌桶中刪除n個令牌，並且數據包被發送到網路；
如果令牌桶中少於n個令牌，則不會刪除令牌，並且認為這個數據包在流量限制之外；
演算法允許最長b個位元組的突發，數據包的速率被限製成常量r。對於在流量限制外的數據包可以以不同的方式處理：
1）被丟棄；
2）放在隊列中當令牌桶中累積了足夠多的令牌時再傳輸；
3）繼續發送，但需要做特殊標記，網路過載時將這些特殊標記的包丟棄。
令牌桶演算法與漏桶演算法（Leaky Bucket）的主要區別：
1）漏桶演算法能夠強行限制數據的傳輸速率，而令牌桶演算法在能夠限制數據的平均傳輸速率外，還允許某種程度的突發傳輸。
2）令牌桶演算法中，只要令牌桶中存在令牌，就允許突發地傳輸數據直到達到用戶配置的上限，它適合於具有突發特性的流量。
RateLimiter是Guava中開源的一個令牌桶演算法工具類，可以輕松實現限流工作。
RateLimiter有兩個實現類：SmoothBursty和SmoothWarmingUp;
兩者區別：
1）都是令牌桶演算法的變種實現
2）SmoothBursty加令牌的速度是恆定的，SmoothWarmingUp會有個預熱期，在預熱期內加令牌的速度是慢慢增加的，直到達到固定速度為止。其適用場景是，對於有的系統而言剛啟動時能承受的QPS較小，需要預熱一段時間後才能達到最佳狀態。
測試示例：
示例1：創建一個令牌桶，每秒生成一個令牌，申請失敗立即返回。使用CountdownLatch計數器模擬多線程並發，調用await()方法阻塞當前線程，當計數完成後，喚醒所有線程並發執行。
示例2：創建一個令牌桶，每秒生成0.1個令牌，即每10s才會有一個令牌，超時時間設置成20s，20s內獲取不到令牌返回失敗，20s內可以生成2個令牌，加上創建時桶里會有一個令牌，超時前最終會有3條線程拿到令牌，並且每個令牌獲取時間相隔10s。使用CountdownLatch計數器模擬多線程並發：調用await()方法阻塞當前線程，當計數完成後，喚醒所有線程並發執行。
參考文檔：
https://ke..com/item/%E4%BB%A4%E7%89%8C%E6%A1%B6%E7%AE%97%E6%B3%95/6597000?fr=aladdin
https://blog.csdn.net/unclecoco/article/details/99583154