標籤

Redis

2020-03-01

2020 某廠面試初體驗,自己落伍了么?

不少企業已經復工一段時間了,招聘季也即將開始。雖說大多數互聯網企業,像騰訊、位元組跳動等,都已經開通遠程面試環節,而且薪資有走高的趨勢。基礎題刷了不少,面試常見問題也背了兩三遍,本來以為準備的挺充足的。但從某廠面試歸來后,發現情況有點揪心,甚至有點懷疑:自己真的落伍了嗎?
比如,面試後端開發崗位時,面試官不僅考察基礎能力更會重點考察高併發、分散式等架構相關的技術背後的思考邏輯,比如:微服務,負載均衡,Redis,RPC等。
但這些技術包含了 N 多優化、N 多細節,對於一些編程的朋友,由於接觸不到一線實戰架構設計,沒有機會去觸及到這些,想想多少是有些委屈。不是不想學,實在是找不到資源!
剛好,趁著這段時間,整理了一套 「微服務+分散式」 的視頻乾貨,講解很透徹。今天分享給大家。這份資料尤其適合以下人群:
1.沒有用過微服務技術,只會用傳統的 SSM 框架
2.用過 Spring Cloud、Dubbo等技術,但是只限於使用,遇到問題基本無法解決 
3.從來沒有系統學習微服務、分散式架構,覺得架構設計是遙不可及的
4.對於微服務、分散式技術有所了解,但尚沒有設計高可用高併發的實踐經歷
學完這份視頻你將獲得哪些收穫?
理解當下最火熱的微服務架構原理及其開源框架;
觸及一線大廠所配備的微服務核心技術內幕知識;
對照自己掌握知識點進行查漏補缺,幫助掃除知識盲區、重構知識體系。
視頻圍繞「如何設計高可用高併發的微服務架構?」的主題,內容由淺入深,同時,對於 Dubbo 負載均衡和服務治理也作出重點解讀。其中涉及到很多微服務相關的核心技術和設計難點,比如
  • 微服務架構究竟學習那些內容?

  • 微服務如何拆分?

  • 微服務如何選型、組合與落地?

  • 微服務治理場景及方法有哪些?

  • 流控、負載、容錯級別、鏈路追蹤參數等都有哪些調整策略?

  • 需求、性能、數據一致性方面都需要注意那些設計細節?

  • 如何設計高可用的微服務架構?……

具體內容有
1
– 如何設計高可用高併發的微服務架構 –
重點內容

1.微服務架構如何拆分

2.微服務架構應用場合

3.微服務架構與Docker容器化

4.微服務架構如何達到99.999%的高可用

5.微服務架構性能怎麼滿足千億次請求調用

6.微服務架構開源框架對比(Spring Boot , Spring Cloud , Dubbo等)

2
– Dubbo 微服務之負載均衡演算法原理分析 –
重點內容
1. 如何理解集群與微服務的關係
2. 負載均衡有哪些業務場景
3. 分析幾種負載均衡的異同點
3
– Dubbo微服務之服務治理演算法原理分析 –
重點內容
1. 微服務治理運作核心原理
2. 微服務治理手段與場景
3. 微服務服務降級、容錯、限流工作機制等流程
本次視頻由「開課吧」 提供,非常感謝開課吧的支持。開課吧的講師都來自純一線互聯網公司,主導了微服務架構在公司多個業務線的推廣和落地,在微服務架構方面有很多實戰乾貨可以分享。相信能夠幫大家解決在工作中遇到的一些技術難點和困惑。
除此之外,分享一位高級架構師朋友近期錄製的視頻—— 「深入認識分散式事務」,對於面試中「分散式事務」這塊是個不錯的補充,比如:

1、事務的基本概念( ACID )

2、理解分散式事務的應用場景及面臨的問題

3、認識分散式事務事務模型

4、演示 LCN 框架分散式事務管理

5、分散式事務解決方案( Atomikos、LCN、TCC、MQ )

6、CAP 定理 & Base 理論及柔性事務

領取方式:添加微信領取這份視頻免費開放,需要的朋友請速速掃描下方二維碼,添加小助理微信諮詢領取。如果覺得視頻不錯,還可以跟小助理諮詢其他合適的學習資料。

長按掃碼兩次  領取視頻
人數較多  請耐心等待
註:精力有限,這次為大家爭取了 166 個名額,先到先得。前 35 名還可以獲得配套的精品講義。領到乾貨后,千萬莫做收藏黨,鏈接有效期僅 5 天哦!
最後,希望大家身體健康,工作順利!提示:點擊「閱讀原文」,快速領取哦!
現在開課吧聯合了廖雪峰和眾知名互聯網技術負責人,針對零基礎和 1-2 年以上工作經驗的 Java 程序員,分別打造了《JavaEE企業級分散式開發工程師》和《JavaEE企業級分散式高級架構師》2 門課程,幫助Java程序員快速提高自身開發能力,為結課學員提供優先推薦服務,提升職場競爭力。
最新一期課程即將開課,想要了解更多課程事宜的朋友可以添加上方微信諮詢。

聲明:本文章為合作推廣,內容和校招薪水公眾號無關

2020-02-17

阿里雲 Redis 開發規範深入解讀,別只會 set、get!

 

  • Key命名設計:可讀性、可管理性、簡介性
  • Value設計:拒絕bigkey
  • 控制Key的生命周期:設定過期時間
  • 時間複雜度為O(n)的命令需要注意N的數量
  • 禁用命令:KEYS、FLUSHDB、FLUSHALL等
  • 推薦使用批量操作提升操作效率
  • monitor命令控制使用時間
  • 寫在最後

Key命名設計:可讀性、可管理性、簡介性

規範建議使用冒號即:進行分割拼接,因為很多Redis客戶端是根據冒號分類的。比如有幾個Key:apps:app:1、apps:app:2和apps:app:3。Redis Desktop Manager能自動歸類到apps目錄下。如下圖所示:

Value設計:拒絕bigkey

規範建議String類型的Value控制在10KB範圍以內。這是因為Redis隨著Value不斷增長,在超過10KB后,有一個非常奇妙的性能拐點,如下圖所示(圖片來自Redis官網:http://redis.cn/topics/benchmarks.html

假設內網帶寬是千兆網卡,即1000MB。假設你的Redis中有一個大Key的Value長度是10KB,並且這個Key的QPS是10W,那麼這一個Key就會把帶寬打滿:10KB*100000=1000MB。

控制Key的生命周期:設定過期時間

儘可能對每一個Key都設置過期時間,這個是非常有益處的。否則,你想想一下,半年以後,一年以後,你的Redis集群中有上百G甚至更多的數據,誰都不知道這些數據哪些是有價值的,哪些已經成為垃圾。如果你的每個Key都設置了過期時間,那麼就不會出現這個問題了。集群在運行過程中,或自動淘汰那些已經不再使用的垃圾緩存數據。

時間複雜度為O(n)的命令需要注意N的數量

這個建議的意思是,以List類型為例,LINDEX、LREM等命令的時間複雜度就是O(n)。也就是說,隨著List中元素數量越來越多,這些命令的性能越來越差。而Redis又是單線程的,如果出現一個慢命令,會導致在這個命令之後執行的命令耗時也會增長,這是使用Redis的大忌。

事實上這也是JDK8為什麼要對HashMap進行鏈條衝突優化:當entry數量不少於64時,如果衝突鏈表長度達到8,就會將其轉成紅黑樹。因為鏈表長度越長,性能會越來越差。

禁用命令:KEYS、FLUSHDB、FLUSHALL等

這些命令應該在搭建Redis環境的時候就要禁用掉(在config配置文件中通過rename-command禁用)。FLUSHDB和FLUSHALL這兩個命令會清空數據,後果可想而知。

至於KEYS命令,還記得那個由於使用這個命令導致幾百萬損失的案例嘛?而且,這個命令的不當使用導致的損失,會隨著你的業務並大越大價值越大而導致損失越大:

推薦使用批量操作提升操作效率

批量命令主要分為兩類,原生命令和非原生命令:

  • 原生命令包括:例如mget、mset、hmget、hmset、LPUSH key value集合等。
  • 非原生命令包括:Pipeline。

合理使用這些命令對操作性能提升是極其巨大 的,尤其在單機Redis或者Sentinel模式下。因為這兩種架構不涉及跨Slot,Redis集群性能也有提升,但是使用會受到一些限制,例如不支持跨Slot的操作。

當然批量雖好,但不要貪多。俗話說的好,貪多嚼不爛。一般不要超過1000,具體限制還與操作數據大小有關。

monitor命令控制使用時間

monitor命令一般是用來觀察redis服務端都在執行哪些命令並實時輸出。例如在其他redis-cli中執行兩個set命令,在monitor中監控結果如下:

afeiMacBook-Pro:redis-3.2.11 afei$ src/redis-cli monitor
OK
1573915193.053188 [0 127.0.0.1:55357] "COMMAND"
1573915197.087383 [0 127.0.0.1:55357] "set" "name" "afei"
1573915217.938838 [0 127.0.0.1:55357] "set" "公 眾 號" "阿飛的博客"

之所以規範建議控制monitor命令的使用時間,是因為隨著monitor命令執行時間越來越長,會導致越來越多的數據積壓在輸出緩衝區,從而導致輸出緩衝區佔用內存越來越大。而且,這種影響會由於Redis併發越高,而更加放大。關於這個問題,美團有一個很經典的案例,感興趣的同學可以搜索關鍵詞:「美團在REDIS上踩過的一些坑-3.REDIS內存佔用飆升 」。

寫在最後

總而言之,任何一門技術都有利有弊,技術的世界里沒有銀彈 。所以,我們對使用到生產環境的任何一個技術,都要非常熟悉:知道它所擅長的和它的弱點,這樣才能結合自己的項目特點,設計出更合理的架構,編寫出最合理的代碼,不給生產環境造成影響,不給公司帶來損失 — 千萬不要成為那個執行KEYS命令導致給公司造成金錢損失的人!