NOSQL(not only sql)；
泛指非關係型數據庫，優點是易擴展、大數據量高性能、多樣靈活的數據模型。
傳統的ACID是什麼?
Atomicity原子性：事務裏面的操作要麼全執行，要麼都不執行；
Consistency一致性：事務開始前和結束時，數據庫的完整性約束不被破壞。比如A向B轉賬，不可能A扣了錢，但是B沒有收到；
Isolation隔離性：併發執行的事務對彼此的中間狀態不可見；
Durability持久性：事務一旦提交，對數據庫的修改就是永久了;
事務的四種隔離級別
讀未提交（Read UnCommited）:會髒讀、不可重複讀、幻讀問題；
【髒讀：指的是一個事務讀取了另一個事務未提交的數據】
【不可重複讀：指的是在一個事務內，多次讀取某一行數據，結果不一致】
【幻讀：指的是一個事務讀取了另一個事務插入的數據，導致前後讀取不一致】
讀已提交（Read Commited）:一個事務當等另一個事務提交後才能讀取數據，會出現不可重複讀和幻讀問題；（Oracle的默認隔離級別）
可重複讀（Repeatable Read）：一個事務開啓時，不允許其他事務修改該事務的數據，會出現幻讀問題；（MySQL的默認隔離級別）
串行化（serializable）:最高的隔離級別，事務串行化執行;
CAP理論？
Consistency：一致性
Availability: 高可用
partition tolerance:分區容錯
redis保證的是CP
redis是單線程，非阻塞IO多路複用模型，默認16個庫；
單線程：避免了不必要的上下文切換和競爭條件消耗cpu；
IO多路複用：採用輪詢的方式依次處理準備好的流，避免了大量無用的操作；
redis常用數據結構？
1. String: 簡單的k-v鍵值對；
2. Hash：是一個String類型的field和value的映射表，hash特別適合用於存儲對象；
3. list:底層實現是雙向鏈表；
4. set：功能與list類似，特殊之處set可以排重；
5. sorted set: 和set相比，增加了一個score參數，使得集合中的元素能夠按照score進行有序排列，並且是插入有序的，即自動排序；
redis的持久化？
1.RDB:
在指定的時間間隔內，把內存中的數據集快照寫入磁盤，恢復的時候直接將磁盤的數據集寫入內存
默認是15分鐘1次，5分鐘100次，1分鐘10000次寫操作觸發
保存的是dump.rdb文件
優點：適合大規模的數據恢復
缺點：
1.會丟失最後一些快照後的所有修改；
2.fork子線程時，內存中的數據被克隆的一份，2倍空間的膨脹性需要考慮；
2.AOF(append only file):
以日誌的形式記錄每個寫操作，只需追加文件不許改寫文件，redis啓動之初會讀取文件來重新執行命令來構建數據
生成是appendonly.aof文件; 默認是關閉的，開啓時 appendonly no 改成yes
重寫機制：當aof文件超過某個設定的閥值時，redis就會啓動文件的壓縮，只保留恢復數據的最小指令集，可以使用命令gbrewirteaof執行。
重寫原理: fork一個新線程來重寫，先寫臨時文件再rename，重寫時不會讀取舊的aof文件，而是把內存中的數據用命令的形式重寫一個新的aof文件；
重寫觸發條件：redis會記錄上次重寫aof文件的大小，默認配置當aof文件是上次重寫的一倍且文件大於64M；
同時開啓rdb和aof時，redis會優先載入aof文件來恢復原始的數據。
比較：
1.aof文件比red文件更新頻繁，優先使用aof還原數據；
2.aof比rdb更安全，更大；
3.aof性能比rdb差；
4.如果兩個都配了，優先加載aof
redis的事務？
一個隊列中一次性、順序性、排他性的執行一系列命令，不保證原子性，同一個事務內如果有一條命令執行失敗，其他的命令仍然會被執行，沒有回滾；
事務相關命令：
1.discard：取消事務，放棄執行事務內的所有命令；
2.exec: 執行事務內的所有命令；
3.mutil：標記一個事務的開啓；
4.watch key[key …]: 監視一個（或多個）key，如果在事務執行之前，這個key被其他命令所改動，那麼事務將被打斷；
5.unwatch: 取消watch命令對key的監視；
watch命令類似於樂觀鎖，樂觀鎖策略：提交版本必須大於記錄當前版本才能被執行；
redis集羣？
**redis主從複製：**讀寫分離、容災恢復；
一類是主數據庫（master）、一類是從服務器（slave）
1.主數據庫可以進行讀寫操作，當發生寫操作的時候自動將數據指令集通道到從數據庫；
2.從服務器一般是隻讀的，一個主庫可以有多個從庫，一個從庫只能有一個主庫；
配置：配從不配主；
從庫配置命令：slaveof 主庫Ip 主庫端口,查看命令 info replication
原理：
1.slave啓動成功後會給master發送一個sync命令；
2.master收到sync命令個啓動後臺存盤程序，同時收集所有接收到的用於修改數據的指令集，在後臺程序執行完成後，傳送整個文件給slave完成一次全量同步；
3.全量複製：slave接收到數據文件時，將其存盤，並加載到內存；
4.增量複製：master繼續將收集到的新指令集發送給slave；
5.slave只要重連master，一次全量複製自動執行；
哨兵模式（sentinel）：
後臺監控主機是否故障，如果故障根據投票數，將slave轉換成master；
redis-cluster集羣：
redis3.0之後版本支持redis-cluster集羣，採用的是無中心結構，每個節點保存數據和整個集羣狀態，每個節點和其他所有節點連接。
結構特點：
1.所有的redis彼此互連（ping-pong），內部使用二進制協議優化傳輸數據和帶寬；
2.節點的fail是通過集羣中超過半數的節點檢測失效才生效;
3.客戶端與redis節點直連，連接集羣中任何一個可用節點即可;
4.redis集羣預分配好16384個slot(槽)所有的節點（不一定平均分配），添加k-v時，對key使用crc16算法得到一個hash，取模16384決定將key放入哪個slot;
多個命令併發執行redis怎麼保證原子性？
1.使用redis事務；
2.使用redis+lua腳本；
如何保證緩存和數據庫雙寫一致性問題？
1.先更新數據庫再更新緩存；
2.如果對數據有強一致性要求，不建議放緩存；
MaxMemory:最大緩存配置。
默認爲0，沒有指定最大緩存，如果有新數據添加，操作最大內存，redis就會崩潰，所以一定要設置。
redis內存數據集上升到一定程度時，就會實行數據淘汰策略。
redis的過期策略和內存淘汰策略：
redis過期策略採用的是定期刪除+惰性刪除
定期清除：redis每隔100ms隨機抽樣檢查，是否有過期的key,有則刪除，但是會導致很多過期的key沒有刪除;
惰性刪除：在獲取某個key的時候redis會檢查一下key是否過期，過期則刪除;
內存淘汰策略有六種：
1.volatile-lru: 從已設置過期時間的數據集中挑選最近最少使用的數據淘汰；
2.volatile-ttl: 從已設置過期時間的數據集中挑選將要過期的數據淘汰；
3.volatile-random：從已設置過期時間的數據集中隨機挑選數據淘汰；
4.allkeys-lru: 當內存不足以容納新寫入數據時，在鍵空間中移除最近最少使用的key（這個是最常用的）；
5.allkeys-random: 當內存空間不足以容納新寫入的數據時，隨機淘汰數據；
6.no-eviction: 禁止驅逐數據，當內存不足以容納新寫入的數據時報錯。
redis常見性能問題？
master最好不要做任何持久化工作，如rdb內存快照和aof日誌文件，如果數據比較重要，某個slave開啓aof備份數據，策略設置爲每秒同步一次;master和slave最好在同一個局域網；儘量避免壓力很大的主庫上增加從庫，不要用圖狀結構，用單向鏈表結構更爲穩定。即： Master <- Slave1 <- Slave2 <-Slave3…
秒殺系統如何設置？高併發會出現什麼問題？
架構設計：
1.將請求攔截在系統上游，降低下游壓力。
秒殺系統特點是高併發，但實際秒殺成功的請求數量卻很少，所以不在前端攔截可能造成數據庫讀寫鎖衝突，甚至導致死鎖，最終請求超時。
2.充分利用緩存：利用緩存可以極大的提高系統讀寫速度。
3.使用消息中間件：消息隊列可以削峯，攔截大量併發請求。
前端設計方案：
1.頁面靜態化：將活動頁面上的所有可靜態元素全部靜態化；
2.禁止重複提交：用戶提交之後按鈕置灰；
3.用戶限流：在某一時間段內，只允許用戶提交一次請求；
後端設計方案：
1.網關限制uid訪問頻率；
2.服務層：採用消息隊列緩存請求和利用緩存應對請求;
3.把減庫存和生成訂單邏輯使用mysql存儲過程實現，減少事務鎖持有時間，避免GC和IO的延遲;