java類的初始化及實例初始化加載順序
https://blog.csdn.net/qq_38815856/article/details/90107122
java最全的單例模式詳解
https://blog.csdn.net/qq_38815856/article/details/90114864
面向對象主要有四大特性
redis持久化
RDB持久化:
是指在指定的時間間隔內將內存中的數據集快照寫入磁盤,實際操作過程是fork一個子進程,先將數據集寫入臨時文件,寫入成功後,再替換之前的文件,用二進制壓縮存儲。
優點:
- 節省磁盤空間
- 恢復速度快
缺點:
- 雖然redis在fork是使用了寫實拷貝技術,但是如果數據龐大還是比較耗費性能。
- 在備份週期在一定時間做一次備份,所以如果redis意外down掉,會丟失最後一次修改。
AOF持久化:
以日誌的形式記錄服務器所處理的每一個寫、刪除操作。查詢操作不會記錄,以文本的方式記錄,可以打開文件看到詳細的操作記錄。
優點:
- 備份機制更穩健,丟失數據概率更低
- 可讀日誌文本查詢處理誤操作
缺點:
- 比RDB佔用更多的磁盤空間
- 恢復備份更慢
- 每次讀寫都同步,有一定性能壓力
redis持久化的兩種方式
https://www.cnblogs.com/chenliangcl/p/7240350.html
Mysql建立索引場景
定義:可以理解爲“排好序的快速查找數據結構”。
優勢:
- 提高檢索效率,降低數據庫的IO成本
- 通過索引列對數據進行排序,降低數據排序的成本,降低了CPU消耗
劣勢:
- 降低了更新表的速度,對錶進行insert、update和delete都會對調整因爲更新所帶來的鍵值變化後的索引信息,因爲更新表會更新這些索引信息
- 所以也是一張表,保存了逐漸與索引字段,並指向實體表的記錄,所以要佔用空間。
使用場景:
- 主鍵自動創建唯一索引
- 頻繁作爲查詢條件的字段
- 查詢中與其他表關聯的字段,外鍵關係建立索引
- 單鍵/組合索引的選擇問題,組合索引性價比更高
- 查詢中排序的字段,排序字段若通過索引去訪問將大大提高排序速度
- 查詢中統計或者分組字段
不適用場景:
- 記錄太少
- 經常改動
- where條件裏用不到的字段
- 過濾性不好的字段(比如性別難以定義出單條數據)
Redis在項目中的使用
數據類型 |
使用場景 |
String |
比如說 ,我想知道什麼時候封鎖一個IP地址。Incrby命令 |
Hash |
存儲用戶信息【id,name,age】 Hset(key,field,value) Hset(userKey,id,101) Hset(userKey,name,admin) Hset(userKey,age,23) ----修改案例---- Hget(userKey,id) Hset(userKey,id,102) 爲什麼不使用String 類型來存儲? Set(userKey,用信息的字符串) Get(userKey) 它會取出多餘的字段序列化,影響性能 |
List |
實現最新消息的排行,還可以利用List的push命令,將任務存在list集合中,同時使用另一個命令,將任務從集合中取出[pop]。 Redis—list數據類型來模擬消息隊列。【電商中的秒殺就可以採用這種方式來完成一個秒殺活動】 |
Set |
特殊之處:可以自動排重。比如說微博中將每個人的好友存在集合(Set)中, 這樣求兩個人的共通好友的操作。我們只需要求交集即可。 |
Zset |
以某一個條件爲權重,進行排序。 京東:商品詳情的時候,都會有一個綜合排名,還可以按照價格進行排名。 |
Elasticsearch 和 Solr 的區別
背景:它們都是基於Lucene搜索服務器基礎之上開發,一款優秀的,高性能的企業級搜索服務器。【是因爲他們都是基於分詞技術構建的倒排索引的方式進行查詢】
區別:
- 當實時建立索引的時候,solr會產生io阻塞,而es則不會,es查詢性能要高於solr。
- 在不斷動態添加數據的時候,solr的檢索效率會變的低下,而es則沒有什麼變化。
- Solr利用zookeeper進行分佈式管理,而es自身帶有分佈式系統管理功能。Solr一般都要部署到web服務器上,比如tomcat。啓動tomcat的時候需要配置tomcat與solr的關聯。【Solr 的本質 是一個動態web項目】
- Solr支持更多的格式數據[xml,json,csv等],而es僅支持json文件格式。
- Solr是傳統搜索應用的有力解決方案,但是es更適用於新興的實時搜索應用。單純的對已有數據進行檢索的時候,solr效率更好,高於es。
- Solr官網提供的功能更多,而es本身更注重於核心功能,高級功能多有第三方插件。