redis操作
brew services start redis 啓動並前臺運行
brew services stop redis 停止服務
redis-server /usr/local/etc/redis.conf 啓動並後臺運行
mysql -uroot 本地登錄
brew services start mysql 前臺
mysql.server start 後臺
redis的功能
redis緩存，可用來做分佈式鎖，支持事務，持久化，lua腳本，lru事件驅動，多集羣方案。
數據類型
- string
- list
- set
- hash
- zset
具體使用場景
數據結構
字典：dictht
跳錶：是有序集合的底層實現。
爲什麼用redis而不用map/guava
緩存分爲本地緩存和分佈式緩存。以 Java 爲例，使用自帶的 map 或者 guava 實現的是本地緩存，最主要的特點是輕量以及快速，生命週期隨着 jvm 的銷燬而結束，並且在多實例的情況下，每個實例都需要各自保存一份緩存，緩存不具有一致性。
使用 redis 或 memcached 之類的稱爲分佈式緩存，在多實例的情況下，各實例共用一份緩存數據，緩存具有一致性。缺點是需要保持 redis 或 memcached服務的高可用，整個程序架構上較爲複雜。
redis和memcache的區別
- redis支持更豐富的數據類型string, list, set, zset,hash, memcache支持簡單的數據類型String。
- Redis支持數據的持久化，可以將內存中的數據保持在磁盤中，重啓的時候可以再次加載進行使用,而Memecache把數據全部存在內存之中。
- 集羣模式：memcached沒有原生的集羣模式，需要依靠客戶端來實現往集羣中分片寫入數據；但是 redis 目前是原生支持 cluster 模式的。
- Memcached是多線程，非阻塞IO複用的網絡模型；Redis使用單線程的多路 IO 複用模型。
redis過期時間
- 定期刪除：redis默認是每隔 100ms 就隨機抽取一些設置了過期時間的key，檢查其是否過期，如果過期就刪除。
- 惰性刪除：查詢的時候再刪。
redis內存淘汰機制（6種策略）
- Volatile-lru
- volatile-ttl
- volatile-random
- allkeys-lru
- allkeys-random
- no-eviction
redis持久化機制
Redis的一種持久化方式叫快照（snapshotting，RDB）,另一種方式是隻追加文件（append-only file,AOF）
RDB：從內存寫入磁盤
AOF：記錄操作的步驟
-
Redis可以通過創建快照來獲得存儲在內存裏面的數據在某個時間點上的副本。快照持久化是Redis默認採用的持久化方式。
-
與快照持久化相比，AOF持久化 的實時性更好，因此已成爲主流的持久化方案。
Redis 4.0 開始支持 RDB 和 AOF 的混合持久化（默認關閉，可以通過配置項 aof-use-rdb-preamble 開啓）。
redis事務
Redis 通過 MULTI、EXEC、WATCH 等命令來實現事務(transaction)功能。
緩存雪崩
緩存同一時間大面積的失效，所以，後面的請求都會落到數據庫上，造成數據庫短時間內承受大量請求而崩掉。
解決辦法：
- 事前：儘量保證整個 redis 集羣的高可用性，發現機器宕機儘快補上。選擇合適的內存淘汰策略。
- 事中：本地ehcache緩存 + hystrix限流&降級，避免MySQL崩掉
- 事後：利用 redis 持久化機制保存的數據儘快恢復緩存
緩存穿透
一般是黑客故意去請求緩存中不存在的數據，導致所有的請求都落到數據庫上，造成數據庫短時間內承受大量請求而崩掉。
解決辦法： 有很多種方法可以有效地解決緩存穿透問題，最常見的則是採用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的bitmap中，一個一定不存在的數據會被 這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。另外也有一個更爲簡單粗暴的方法（我們採用的就是這種），如果一個查詢返回的數據爲空（不管是數 據不存在，還是系統故障），我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過五分鐘。
跳錶
與紅黑樹等平衡樹相比，跳躍表具有以下優點：
- 插入速度非常快速，因爲不需要進行旋轉等操作來維護平衡性；
- 更容易實現；
- 支持無鎖操作。
memcache
僅支持字符串類型
哨兵
主從複製
git和SVN
git是分佈式版本控制
svn是集中式版本控制
集中式版本控制只有中心服務器擁有一份代碼，而分佈式版本控制每個人的電腦上就有一份完整的代碼。
集羣
將多臺服務器組成集羣，使用負載均衡將請求轉發到集羣中，避免單一服務器的負載壓力過大導致性能降低。
服務降級
服務降級是系統爲了應對大量的請求，主動關閉部分功能，從而保證核心功能可用。
發佈訂閱模式
發佈與訂閱模式和觀察者模式有以下不同：
- 觀察者模式中，觀察者和主題都知道對方的存在；而在發佈與訂閱模式中，生產者與消費者不知道對方的存在，它們之間通過頻道進行通信。
- 觀察者模式是同步的，當事件觸發時，主題會調用觀察者的方法，然後等待方法返回；而發佈與訂閱模式是異步的，生產者向頻道發送一個消息之後，就不需要關心消費者何時去訂閱這個消息，可以立即返回。
消息隊列
使用場景：異步處理，流量削峯，應用接耦。
kafka
Kafka是一個分佈式的消息發佈-訂閱系統，能夠支撐海量數據的數據傳遞。
- broker：Kafka服務器，負責消息存儲和轉發
- topic：消息類別
redis分佈式鎖和實現
降級策略
Redis持久化方式、如何解決AOF文件過大的問題
消息中間件瞭解嗎，說說爲什麼要用消息中間件
項目中的緩存不一致怎麼解決的
redis內存滿了會怎麼樣