一、你的專案中快取粒度是如何選擇的?
快取粒度一共分為4種.
1.快取某個數值:一個鍵只儲存一個值,價效比較低,使用率低,如果儲存的話我們使用redis的String
2.快取資料物件:資料庫記錄對應的具體資料,優點是可以多次複用,String,hash
3.快取資料集合:資料庫查詢對應的結果集,可以和資料物件配合使用,方便資料物件的重用,hash,list,set,zset,String(zset,String)
4.快取試圖響應:試圖返回的相應資料,複用性比較差,String
所以我們專案中主要對資料集合+資料物件進行快取,他們的優點是複用性強,節省記憶體空間.
二、使用過redis的那些格式做過快取,其他應用場景和優缺點是什麼?
包括list,zset,set,hash和json字串
其中我們使用過json字串和zset
set用來存放無序去重的資料, 如果有判斷是否存在的需求
zset有排序的需要list,如果說是按時間查詢, 查詢的結果固定, 不需要分頁的情況下,我們使用list因為查詢的比較快
但如果有額外排序要求, 而且需要分頁, 我們使用zset(查詢時間跟查詢的長度和資料量有關,跟查詢區別無關, 查詢速度比較均衡),
增加資料效率和儲存的資料量負相關,資料量越大,新增時間越長,查詢資料效率和儲存的資料量負相關,並且和查詢的結果集資料量有關
json字串需要進行轉換,使用pickle模組提高效能,無法單獨更新某個欄位,節省空間
我們通過Redis的Cluster叢集來實現擴充套件儲存空間,在不停掉Cluster叢集環境的情況下通過redis-trib.rb指令碼檔案來動態的往叢集環境中增加主,從節點,也可以動態的從叢集環境中刪除節點
配置連線https://www.cnblogs.com/PatrickLiu/p/8473135.html
1. 建立兩個redis例項, 修改配置檔案ip和埠號
2. 把建立的兩個例項新增到cluster叢集中# ruby redis-trib.rb add-node 192.168.127.130:7006 192.168.127.130:7000
3. cluster nodes 進行驗證節點 , (預設都是主master)
4. 從主節點master上抽取一些slots分給要加入的這個主節點 # ruby redis-trib.rb reshard 192.168.127.130:7000
5. 選擇接收資料槽的節點和資料槽產生的方式 選擇all
6. 執行分配計劃 yes_
7. 增加這從節點7007到叢集中 # ruby redis-trib.rb add-node 192.168.127.130:7007 192.168.127.130:7000
8. 將從7007節點作為主節點的從節點實現主從配置 進入 7007redis
執行> cluster replicate 71ecd970838e9b400a2a6a15cd30a94ab96203bf(這裡是主節點的ID)
首先把redis的 maxmemory 調到最大, 然後把這個maxmemory-policy調成LFU淘汰策略
使用過期策略和快取淘汰機制
過期策略中選擇惰性過期+定期過期(每100ms對設定了過期時間的資料隨機查詢並刪除過期資料)
快取淘汰中有LFU和LRU.LFU:優先淘汰不是頻繁使用的資料,有定期衰減這個機制,由於消費較高,
所以我們基本會選擇LRU:優先淘汰不是最近使用的資料.淘汰策略maxmemory-policy volatile-lru
四、快取穿透和快取雪崩是什麼,如何解決?
快取穿透，是指查詢一個資料庫一定不存在的資料。正常的使用快取流程大致是，資料查詢先進行快取查詢，
如果key不存在或者key已經過期，再對資料庫進行查詢，並把查詢到的物件，放進快取。如果資料庫查詢物件為空，則不放進快取.
解決辦法:1.對於資料庫中不存在的資料,也對其在快取中設定預設值一般過期時間會比較短
2.可以設定一些過濾規則, 如布隆過濾器(演算法, 用於判斷資料是否包含在集合中), 將所有可能的值錄入過濾器, 如果不包含直接返回None, 有誤殺概率
快取雪崩，是指在某一個時間段，快取集中過期失效。
1.設定過期時間時,新增隨機值,讓過期時間進行一定程度分散
2.多級快取的方式來處理
3.利用鎖/佇列的形式
五、專案中使用的快取模式是什麼,遇到過哪些問題?
1.Cache Aside 更新模式(同時更新快取和資料庫) 更新丟失(先更新資料庫,後刪除快取), 快取穿透, 快取雪崩
2.Read/Write Through 更新模式(通讀通寫) 應用程式只需要維護快取，資料庫的維護工作由快取代理
read through : 在查詢操作中更新快取，也就是說，當快取失效的時候，Cache Aside 模式是由呼叫方負責把資料載入入快取，而 Read Through 則用快取服務自己來載入。
write through: 和 Read Through 相仿，不過是在更新資料時發生。當有資料更新的時候，如果沒有命中快取，直接更新資料庫，然後返回。
如果命中了快取，則更新快取，然後由快取自己更新資料庫（這是一個同步操作）
3.Write Behind Caching 更新模式 就是在更新資料的時候，只更新快取，不更新資料庫，而我們的快取會非同步地批量更新資料庫,這個設計的好處就是直接操作記憶體速度快。
因為非同步，Write Behind Caching 更新模式還可以合併對同一個資料的多次操作到資料庫，所以效能的提高是相當可觀的。
但其帶來的問題是，資料不是強一致性的，而且可能會丟失。另外，Write Behind Caching 更新模式實現邏輯比較複雜，因為它需要確認有哪些資料是被更新了的，哪些資料需要刷到持久層上。
只有在快取需要失效的時候，才會把它真正持久起來。
六、讀寫分離對事務是否有影響？
對於寫操作包括開啟事務和提交或回滾要在一臺機器上執行，分散到多臺master執行後資料庫原生的單機事務就失效了。
對於事務中同時包含讀寫操作，與事務隔離級別設定有關，如果事務隔離級別為read-uncommitted 或者 read-committed，讀寫分離沒影響，
如果隔離級別為repeatable-read、serializable，讀寫分離就有影響，因為在slave上會看到新資料，而正在事務中的master看不到新資料。
七、varchar和char的區別,utf8字符集下varchar最多能存多少個字元 ?
char的長度不可變,查詢效率高,可能造成儲存浪費,用於手機號.varchar長度可變,,查詢效率低,節省空間,用於使用者名稱.在UTF8字符集下最大長度不能超過21845
八、primary key和unique的區別？
unique可空,可以在一個表裡的一個或多個欄位定義;
primary key不可空不可重複,在一個表裡可以定義聯合主鍵.
九、什麼是外來鍵約束?
不使用SQL建立外來鍵, 而是定義普通的鍵去記錄主鍵(邏輯外來鍵) 仍然可以多表聯查,刪除和更新效率高,但是會有出錯的風險,有程式邏輯來控制.
十、什麼是索引?
為了提高查詢速度提供的一種資料結構, 類似書的目錄, 方便快速查詢出資料, 而不是從頭到尾的依次對比,優點:增加查詢速度,缺點:增加資料庫的儲存空間,減慢增刪改速度
十一、索引的分類?
普通索引index:不要用可空列作為索引, 易出錯.
適合資料量超過300的表,經常與其他表進行連線的表，經常出現在Where子句中的欄位，選擇性高的欄位和小欄位.頻繁進行資料操作的表，不要建立太多的索引；適用於改動小,查詢多的場景.
聯合索引:聯合索引必須符合最左原則, 否則無效.
主鍵索引:建立主鍵後自動生成
唯一索引:設定唯一約束後自動生成
外來鍵索引:設定外來鍵約束後自動生成
十二、索引的原理
Mysql的索引儲存結構為B+tree結構 平衡二叉樹.
聚簇索引: 主鍵B+樹在葉子節點直接儲存的是資料行, InnoDB引擎使用.
優點: 主鍵查詢的速度非常快
缺點: 增刪改比較慢,其它的主鍵查詢要二次查詢
非聚簇索引: 主鍵B+樹在葉子節點只是儲存真正資料行的地址, 資料行和索引儲存在不同的結構中,MyISAM引擎使用
優點: 增刪改比較快, 非主鍵的查詢也比較快
缺點: 不支援事務
十三、InnoDB的主鍵為什麼選擇自增 ?
資料和主鍵索引是繫結在一起的, 主鍵自增就會讓資料順序新增到B+Tree中, 寫完一頁再寫下一頁, 不需要為了索引的排列而移動資料和頁分裂, 並且移動和頁分裂也會降低查詢速度
十四、能不能使用業務欄位作為主鍵(業務主鍵) ?
可以, 但不好
使用自增主鍵效能會快很多
業務欄位更新頻繁,一旦修改,索引也要跟著變,成本較高
所以一般採用和業務無關的資料充當主鍵(邏輯主鍵)
十五、聯合主鍵
將多個業務鍵聯合定義為主鍵
優點:節省空間
缺點:和業務有關, 頻繁改動,不是自增,效能差,儘量不要用
十六、三正規化和反正規化設計
第一正規化: 欄位具有原子性, 不可拆分
第二正規化: 依賴於全部主鍵, 而非部分主鍵
第三正規化: 只依賴於主鍵, 非主鍵欄位互不依賴
目的是減少冗餘欄位
如果單獨定義欄位來記錄,該欄位就稱為冗餘欄位,這種設計稱為反正規化設計.
通過加入冗餘欄位,來提高資料庫的查詢速度,減少關聯查詢,用空間換取時間
正規化是武功招式, 如何運用全看自己, 也有缺點, 查詢速度高了,會增加很多寫入操作
十七、分庫分表前後的問題?
分表分庫前的問題,
使用者請求量太大,解決辦法:分散請求到多個伺服器上
單庫太大,解決方法:切分成更多更小的庫
單表太大,解決方法:切分成多個資料集更小的表
分表分庫後的問題,
事務支援,分表分庫後,就成了分散式事務
多庫結果集合並
跨庫join
十八、mysql鎖
它的目的是解決併發情況下資源搶奪問題, 維護資料的一致性,
mysql的鎖雖然開發者可以手動設定, 但比較影響併發性, 一般會使用樂觀鎖代替,由於mysql會自動使用鎖, 所以需要了解鎖機制, 以便優化資料庫併發能力.
分為行級鎖和表級鎖.
行級鎖:對資料行鎖定, 併發好, 資源消耗多
表級鎖:對整個表鎖定, 併發差, 資源消耗少
十九、鎖和事務,鎖和事務的優化建議
無論操作是否在事務中, 都可以獲取鎖, 只不過在事務中, 獲取的鎖只有執行完事務才會釋放
優化建議:
1.使用讀取已提交事務隔離級別
2.精心設計索引
3.選擇合理的事務大小
4.最好一次性請求足夠級別的鎖
5.約定以相同的順序訪問各表
6.用相等條件訪問資料
7.除非必須，查詢時不要顯式加鎖
二十、行鎖與讀寫許可權
行共享鎖:獲取行共享鎖後, 當前事務可以讀,不一定能寫;其他事務可以讀,不能寫.
共享鎖容易出現死鎖陷阱
行排他鎖:獲取後,當前事務既可以讀,也可以寫;其他事務可以讀,不能寫
行鎖是通過給索引加鎖實現的,如果查詢時沒有觸發索引,就會鎖表,使用讀取已提交事務隔離級別,只鎖行,不鎖表
二十一、什麼是間隙鎖
對於鍵值在條件範圍內但並不存在的記錄，叫做'間隙'
在擊中索引的情況下,獲取行鎖時,InnoDB不僅會對符合條件的已有資料行加鎖,也會對這個'間隙'加鎖
InnoDB完整的行鎖機制為 下鍵鎖
缺點是會阻塞符合條件的插入操作,目的是防止幻讀.
解決辦法:1.儘量不要對有頻繁插入的表進行範圍條件的檢索
2.使用讀取已提交事務隔離級別
3.使用唯一索引或主鍵索引進行查詢
二十二、mysql事務和事務隔離級別
目的: 保證資料庫安全穩定執行的技術
四大特性: ACID 原子性 一致性 隔離性 永續性
原子性: 要麼都成功, 要麼都失敗,實現機制是undo log
一致性:操作前後, 系統穩定, 資料一致,原子性不代表一致性:
髒讀/不可重複讀/幻讀: 解決辦法:調整事務級別
提交事務後, 只有一半操作持久化成功: 解決辦法: redo log
隔離性:每個事務是獨立的,相互不會影響,實現機制多版本併發控制+鎖(MVCC+鎖)
永續性:保證事務的執行結果一定能在資料庫中同步完成, 無論資料庫所在硬體是否癱瘓,實現機制: redo log
原子性 永續性 隔離性 實現了一致性
事務隔離級別:四個級別, 只會用到讀已提交和可重複讀這兩個
mysql預設為可重複讀,更建議使用讀取已提交,不會加間隙鎖,索引沒觸發,不會鎖表,只是鎖行,不可重複讀和幻讀問題, 一般不需要管, 如果有強制要求, 加悲觀鎖/樂觀鎖
二十三、MVCC多版本併發控制
簡單來說就是對資料做了多版本控制,事務隔離級別中的RC和RR就是MVCC實現的
RR可重複讀級別:
快照讀: select * from xx: # 在事務中無論讀多少次都和第一次讀的結果一樣
當前讀: select * from xx lock in share mode; select * from xx for update和insert update delete 語句
RC讀取已提交級別:
仍然有快照讀, 事務提交成功的資料可以讀取得到, 但讀不到未提交的資料
二十四、MyISAM 和InnoDB
MyISAM:只支援表級鎖
表讀鎖/共享鎖:獲取後, 其他請求可以讀不能寫,對MyISAM的讀操作，不會阻塞其他使用者對同一表讀請求，但會阻塞對同一表的寫請求；
表寫鎖/排它鎖:獲取後, 其他請求既不能讀也不能寫,對MyISAM的寫操作，則會阻塞其他使用者對同一表的讀和寫操作；
加鎖方式:1.資料庫自動管理,查詢前給設計的表新增讀鎖, 更新前(增刪改)給涉及的表加寫鎖
2.MyISAM在執行查詢語句前，會自動給涉及的所有表加共享鎖，一旦上共享鎖,其他程式就不能獲取排它鎖, 就不能進行寫操作, 在執行更新、刪除、增加操作前，會自動給涉及的表加寫鎖，這個過程並不需要使用者干預
3.MyISAM表的讀操作和寫操作之間，以及寫操作之間是序列的。
4.當一個執行緒獲得對一個表的寫鎖後，只有持有鎖執行緒可以對錶進行更新操作。其他執行緒的讀、寫操作都會等待，直到鎖被釋放為止。
InnoDB:支援行級鎖和表級鎖, 優先使用行級鎖
行共享鎖:獲取後, 其他事務也可以獲取目標集的共享鎖, 但不能獲取目標集的排他鎖
行排它鎖:獲取後, 其他事務既不能獲取目標集的共享鎖, 也不能獲取對應的排它鎖
加鎖方式:1.對於查詢語句，innodb不會加任何鎖，也就是可以多個併發去進行查詢的操作，不會有任何的鎖衝突，因為根本沒有鎖。
2.對於增加、刪除、更新操作，innodb會自動給涉及到的資料加排他鎖，只有查詢操作需要我們手動設定排他鎖。
3.執行增刪改前自動加排它鎖
4.查詢語句不需要任何鎖, innoDB也不新增任何鎖
5.增刪改必須獲取排它鎖, 普通查詢不需要獲取任何鎖
二十五、REDO和UNDO
UNDO:作用:1.用於回滾,現實事務的原子性
2.實現多版本併發控制(MVCC)
原理:在資料操作只從之前,先將牽扯到的資料備份到UNDO LOG, 然後再進行資料的操作
如果出現回滾操作,系統可以利用Undo Log中的備份將資料恢復到事務開始之前的狀態
Undo log必須先於資料持久化到磁碟,如果在D,E之間系統崩潰, undo log是完整的,可以用來回滾事務
REDO:記錄的是新資料的備份
作用:保證事務永續性
原理:1 新資料寫入記憶體緩衝區後,將執行的更新操作寫入redo log,再將資料寫入磁碟(一定發生在redo寫入之後,但未必立即執行)
2.當系統崩潰時,雖然資料沒有寫入磁碟,但是Redo Log已經持久化,系統可以根據Redo log的內容,將所有資料恢復到最新的狀態
3.雖然redo log和寫入資料庫 都是寫入磁碟,但是redo log的效能高於寫入資料庫(redo log只寫入命令,不新增事務的判斷)
資料庫恢復:1.mysql重啟後自動進行 2.先REDO,再UNDO 3.進行恢復時,
3.1 REDO不區分事務,會重複做所有操作(包括未提交的操作和最終回滾的操作)
3.2 然後再由UNDO來回滾未提交和要執行回滾的事務
二十六、資料庫引擎
實現資料儲存的不同解決方案
InnoDB mysql5.5開始 預設
支援事務,支援行級鎖和表級鎖,併發訪問時效率高,支援外來鍵約束,插入/更新/主鍵查詢快,需要記憶體和硬碟多,常規推薦使用
MyISAM:不支援事務,不支援外來鍵約束,只支援表級鎖,批量插入/查詢/count速度快
簡單, 適合小型專案和以批量插入和查詢為主的系統(內部管理系統)
二十七、什麼是RPC,gRPC?
RPC (遠端過程調同) 是一個計算機通訊協議
作用: 可以以函式形式來呼叫另一臺計算機上的程式
優點: 使用自定義的二進位制形式進行資料傳輸, 效率極高
應用場景:子系統之間進行資料互動
grpc:谷歌開發的高效能的RPC框架
優點:1.使用http2.0標準, 支援雙向流和多路複用 2.支援多語言和多平臺
http2.0利用二進位制的分幀層對請求頭,請求體進行分組分包, 這樣就允許在同一個連線可以傳送和接收多個請求的資料
主要特點:二進位制分幀層,多路複用,頭部壓縮,伺服器推送
分為crontab和apschedule
crontab:是linux系統一個內建命令,依賴於linux系統,無動態管理任務,適合於普通的靜態任務.
apschedule:獨裡的定時器程式,可以方便的管理定時任務,需要動態生成.
支援三種觸發器
date 只執行一次
interval 週期執行 引數時間間隔
cron 週期執行 引數時間
二十九、快取更新問題
mysql和redis是兩個獨立的系統,在併發環境下,無法保證更新的一致性,解決辦法:更新資料時,先寫入mysql,再刪除快取,設計分散式鎖或使訊息佇列序列處理
三十、快取有效期和淘汰策略
設定有效期的作用:1.節省空間 2.做到資料弱一致性，有效期失效後，可以保證資料的一致性
過期策略:1.定時過期:效率太低,每個資料都需要設定定時器進行計數
2.惰性過期:查詢時,才去檢查資料的有效期,如果過期,則返回nil,並刪除過期資料
3.定期過期:每隔100ms,隨機取出一部分資料進行過期校驗,如果過期, 刪除資料
redis中選擇惰性過期+定期過期 (每100ms對設定了過期時間的資料隨機查詢並刪除過期資料)
LRU:least recently use 優先淘汰不是最近使用的資料
LFU:least frequently use 優先淘汰不是頻繁使用的資料
採用了定期衰減的機制, 防止舊資料始終無法刪除
缺點:需要每條資料維護一個使用計數,還需要定期衰減
三十一、為什麼不用定時過期策略?
定時過期,用一個定時器來負責監視key,過期則自動刪除。雖然記憶體及時釋放，但是十分消耗CPU資源。在大併發請求下，CPU要將時間應用在處理請求，而不是刪除key,因此沒有采用這一策略.
三十二、定期過期+惰性過期是如何工作的呢?
定期過期，redis預設每個100ms檢查，是否有過期的key,有過期key則刪除。需要說明的是，redis不是每個100ms將所有的key檢查一次，
而是隨機抽取進行檢查(如果每隔100ms,全部key進行檢查，redis豈不是卡死)。因此，如果只採用定期過去策略，會導致很多key到時間沒有刪除。
於是，惰性過期派上用場。也就是說在你獲取某個key的時候，redis會檢查一下，這個key如果設定了過期時間那麼是否過期了？如果過期了此時就會刪除。
三十三、採用定期過期+惰性過期就沒其他問題了麼?
不是的，如果定期過期沒刪除key。然後你也沒即時去請求key，也就是說惰性過期也沒生效。這樣，redis的記憶體會越來越高。那麼就應該採用記憶體淘汰機制。
三十四、JWE
對稱加密:
代表演算法 des 3des aes,速度快
非對稱加密:
代表算範 rsa
速度慢,不適合大型資料加密
加密時,一般公鑰加密,私鑰解密,與簽名相反
私鑰唯一,使用私鑰簽名,公鑰驗籤,可以保證簽名者身份唯一
主要用於資料加密
最佳方案 (JWE)
傳輸的資料使用對稱加密, 生成資料密文, 對稱加密祕鑰是隨機的,為了防止資料篡改,對資料密文進行摘要認證,摘要認證的祕鑰也是隨機的,對稱加密的祕鑰和摘要認證的祕鑰使用非對稱加密進行處理
JWE的耗時遠高於JWS
三十五、為什麼使用JWT進行狀態保持?
因為APP不支援狀態保持,狀態保持有同源策略,無法跨伺服器傳遞,所以不採用session.session依賴於cookie不安全,session存在於資料庫,使用者多時,影響資料庫效能
三十六、什麼是JWT?
JWT不可逆加密部分主要用於資料認證, 防止資料被修改
三十七、CDN加速是對網站所在伺服器加速，還是對其域名加速？
CDN是隻對網站的某一個具體的域名加速。如果同一個網站有多個域名，則訪客訪問加入CDN的域名獲得加速效果，訪問未加入CDN的域名，或者直接訪問IP地址，則無法獲得CDN效果。
三十八、CDN使用後，原來的網站是否需要做修改，做什麼修改？
一般而言，網站無需任何修改即可使用CDN獲得加速效果。只是對需要判斷訪客IP程式，才需要做少量修改。
三十九、如何解決重新整理問題？
1.手機號+驗證碼（或帳號+密碼）驗證後頒發介面呼叫token與refresh_token（重新整理token）
2.Token 有效期為2小時，在呼叫介面時攜帶，每2小時重新整理一次
3.提供refresh_token，refresh_token 有效期14天
4.在介面呼叫token過期後憑藉refresh_token 獲取新token
5.未攜帶token 、錯誤的token或介面呼叫token過期，返回401狀態碼
6.refresh_token 過期返回403狀態碼，前端在使用refresh_token請求新token時遇到403狀態碼則進入使用者登入介面從新認證。
四十、判斷問題發生在前端還是後端?
如果前端為網頁，可以通過網頁除錯工具裡面的network判斷
如果前端不是網頁，比如app，通過日誌的訪問請求記錄判斷
如果是後端出現的問題，通過pycharm或日誌來判斷
四十一、資料庫優化
1.在進行表設計時，可適度增加冗餘欄位(反正規化設計)，減少JOIN操作；
2.多欄位表可以進行垂直分表優化，多資料表可以進行水平分表優化；
3.選擇恰當的資料型別，如整型的選擇；
4.對於強調快速讀取的操作，可以考慮使用MyISAM資料庫引擎；
5.對較頻繁的作為查詢條件的欄位建立索引；唯一性太差的欄位不適合單獨建立索引，即使頻繁作為查詢條件；更新非常頻繁的欄位不適合建立索引；
6.編寫SQL時使用上面的方式對SQL語句進行優化；
7.使用慢查詢工具找出效率低下的SQL語句進行優化；
8.構建快取，減少資料庫磁碟操作；
9.可以考慮結合使用內在型資料庫，如Redis，進行混合儲存。
四十二、Redis事務
語法:
1.MULTI:開啟事務, 後續的命令會被加入到同一個事務中
事務中的操作會發給服務端, 但是不會立即執行, 而是放到了該事務的對應的一個佇列中, 服務端返回QUEUED
2.EXEC:執行EXEC後, 事務中的命令才會被執行,事務中的命令出現錯誤時, 不會回滾也不會停止事務, 而是繼續執行
3.DISCARD:取消事務, 事務佇列會清空, 客戶端退出事務狀態
ACID:
1.原子性: 不支援, 不會回滾並且有錯誤也會繼續執行
2.隔離性: 支援, 單程式,單執行緒, 事務中的命令順序執行, 並且不會被其他客戶端(事務)打斷(先EXEC的先執行)在事務中的會一次性執行完再執行下一個命令(事務)
3.永續性:不支援, redis資料丟失
4.一致性: 不支援, 如果強制使用一致性,需要加樂觀鎖(watch監聽)
watch:redis實現的樂觀鎖 可以實現秒殺超賣需求
事務開啟前, 設定對資料的監聽, EXEC時, 如果發現資料發生過修改, 事務會自動取消
事務EXEC後, 無論成敗, 監聽會被移除
setnx和悲觀鎖:setnx鍵不存在,才會設定成功
四十三、Redis持久化
分為RDB快照儲存和AOF只追加檔案
RDB:將記憶體中的所有資料 完整的儲存到硬碟中,配置中設定自動持久化策略
優點:方便資料備份:由於儲存到單獨的檔案中,易於資料備份
寫時複製:子程式單獨完成持久化操作,父程式不參與IO操作, 最大化redis效能
恢復大量資料時,速度優於AOF
缺點:不是實時儲存資料,如果redis意外停止工作,則可能會丟失一段時間的資料
資料量大時,fork程式會比較慢,持久化時使redis響應速度變慢
AOF:只追加而不是全部重新寫入,追加命令而不是資料
優點:更可靠 預設每秒同步一次操作,最多丟失一秒資料
可以進行檔案重寫,以避免AOF檔案過大
缺點:相同資料集,AOF檔案比RDB體積大,恢復速度慢
除非是不同步情況,否則普遍要比RDB速度慢
四十四、如何選擇RDB和AOF?
對於更新頻繁,一致性要求不是非常高的資料可以選擇使用redis進行持久化儲存
RDB or AOF:
資料安全性要求高, 都開啟
可以接受短時間的資料丟失, 只使用RDB
即使使用AOF,最好也開啟RDB,因為便於備份並且回覆速度快,bug更少
使用redis進行一部分資料的持久化儲存
兩種持久化機制都開啟
四十五、什麼是哨兵機制?
監控redis伺服器的執行狀態,可以進行自動故障轉移,實現高可用,與資料庫主從配合使用的機制
特點:
1.獨自的程式, 每臺redis伺服器應該至少配置一個哨兵程式
2.監控redis主伺服器的執行狀態
3.出現故障後可以向管理員/其他程式發出通知
4.針對故障,可以進行自動轉移, 並向客戶端提供新的訪問地址
至少在3臺伺服器上分別啟動至少一個哨兵
如果只有一臺,則伺服器當機後,將無法進行故障遷移
如果只有兩臺,一旦一個哨兵掛掉了,則投票會失敗
心跳機制和投票裁決
四十六、什麼是叢集?
多個節點共同儲存資料,它能擴充套件儲存空間,提高吞吐量,提高寫的效能,不在區分資料庫,只有0號庫,單機預設0-15,不支援事務,管道和多值操作.
要求至少三主三從,要求必須開啟AOF持久化,自動選擇叢集節點進行儲存,預設整合哨兵,自動故障轉移
redis叢集不能支援事務和WATCH, 併發控制只能自己設計悲觀鎖,叢集負責實現快取設計
四十六、資料庫設計?
索引的原理採用了B+Tree平衡二叉樹結構,有聚簇索引和非聚簇索引,
聚簇索引:主鍵B+樹在葉子節點直接儲存的是資料行, InnoDB引擎使用.優點: 主鍵查詢的速度非常快,缺點: 增刪改比較慢,其它的主鍵查詢要二次查詢
非聚簇索引:主鍵B+樹在葉子節點只是儲存真正資料行的地址, 資料行和索引儲存在不同的結構中,MyISAM引擎使用優點: 增刪改比較快, 非主鍵的查詢也比較快
缺點: 不支援事務
所以我們大多數的表都使用了聚簇索引和InnoDB引擎,因為InnoDB引擎支援事務,可以進行事務回滾,恢復速度快,還支援行級鎖和表級鎖,
提高併發訪問時的效率,支援外來鍵約束,插入更新主鍵查詢快,但是需要的記憶體和硬碟多,
而MyISAM引擎不支援事務和外來鍵約束,只支援表級鎖,批量插入和查詢速度快,適合小型專案,我們專案中系統公告表因為基本不會修改,
不存在大量併發寫操作,也就不需要行級鎖和事務為資料安全穩定做保障,查詢多,MyISAM的查詢速度會更快.
當初我們嘗試使用業務欄位作為主鍵,結果是可以使用,但是不太好,業務欄位更新頻繁,一旦修改,索引也要跟著變,成本比較高,所以我們採用和業務無關的資料充當主鍵.