一、你的項目中緩存粒度是如何選擇的?

緩存粒度一共分為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滿了怎么辦,如何在不停止服務器的前提下擴容?

我們通過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利用二進制的分幀層對請求頭,請求體進行分組分包, 這樣就允許在同一個連接可以發送和接收多個請求的數據 主要特點:二進制分幀層,多路復用,頭部壓縮,服務器推送

?

二十八、APSchedule定時器

分為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的查詢速度會更快.
當初我們嘗試使用業務字段作為主鍵,結果是可以使用,但是不太好,業務字段更新頻繁,一旦修改,索引也要跟著變,成本比較高,所以我們采用和業務無關的數據充當主鍵.

?

轉載于:https://www.cnblogs.com/Infernal/p/11233850.html

總結

以上是生活随笔為你收集整理的Flask项目常见面试问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。