大多數(shù)管理者的困境


   
作為一名專業(yè)的教練，我經常會被問到：

教練，我的團隊溝通不暢該怎么辦？

教練，我的團隊執(zhí)行力不強要如何處理？

教練，我的團隊里沒有人才可用要如何做呢？

教練，我的團隊士氣很低怎樣激勵他們呢？

教練，我的團隊經常達不成目標能給些建議嗎？

教練，我的團隊沒有凝聚力有什么好的方法嗎？

教練，我的團隊沒有能量，我要怎么給他們賦能呢？
……
 
教練與企業(yè)管理者的對話：



 
每當這個時候，我都會問這些企業(yè)的負責人，
 
一個雞蛋如果從外給予壓力，最終會怎什么呢？

他們有的說，會形成碎雞蛋，也有人說，打破了可以做成炒雞蛋，還有人說，可以用雞蛋清敷在臉上做面膜，人類的想象力總是讓人出乎意料……

我又問到，
 
那如果從里面給到動力，最后破殼而出，又會發(fā)生什么呢？

   
所有人的回答幾乎都是一樣的，一只有著生命力的小雞.

我又問了一個問題，
 
我說假如你可以讓你的員工具備破殼而出的生命力，你覺得企業(yè)會發(fā)生什么呢？

他們說，那簡直太棒了，每個人都能自發(fā)地去做事，而且?guī)еで楹蛣恿Γ麄€企業(yè)一定朝氣蓬勃，充滿斗志，但是，教練，我怎么做才能讓他們具備這樣的生命力呢？
 
我說，這是一個好問題，你覺得母雞是怎么做的呢？

他們說，母雞每天都會坐在雞蛋上，哪都不去玩，全身心投入，給到雞蛋持續(xù)的關懷和溫度，并且堅持21天，直到小雞可以從蛋殼中走出來.


   
那母雞孵化小雞這個過程給到你什么啟發(fā)呢？
 
他們說，我也需要給到自己團隊這樣的關懷和支持，用心去孵化他們內在的動力，幫助他們釋放出潛能，為他們創(chuàng)造適合他們成長的環(huán)境和土壤，以及給予更多的陽光和水，我相信他們一定能由內而外的活出有能量的狀態(tài)，到那時無論什么困難和挑戰(zhàn)都會迎刃而解.
 
每個人都是自己生命中的天才

 
他們分享完我就直接鼓掌，我一直都認為，每個人都是自己生命中的天才，而且我也是這樣去踐行的，無論是多大的企業(yè)家，還是最普通的員工都可以活出自己內在的智慧，并且解決生命中的困境.

馬斯洛也曾說過類似的話，他說“人并不是被澆鑄或塑造成人的，而是依靠自身實現(xiàn)潛能的，環(huán)境對人的成長象土壤、陽光和水對于植物一樣，只能促進潛能的現(xiàn)實化。”
 
生命生長需要時間


無論是打破一個雞蛋，還是一花一世界，萬物皆具潛能，只是我們只盯在相上，只盯在結果上，卻沒有為結果投入更多的時間和耐心，即使我們今天看到的太陽的光芒，也不是今天太陽發(fā)出來的.

根據(jù)科學家的計算，從太陽發(fā)出光到地球需要8分20秒左右的時間，這就意味著，當我們生命中出現(xiàn)了至暗時刻，不用著急，也不用慌張，因為太陽光在路上，給它一點時間，至暗終會迎來光明.

以下文章由IT外包服務商北京艾銻無限科技發(fā)展公司整理

 

it運維知識教您緩存的三種方式
 
 
緩存是現(xiàn)在系統(tǒng)中必不可少的模塊，并且已經成為了高并發(fā)高性能架構的一個關鍵組件。現(xiàn)在我們來分析一下使用緩存的正確姿勢。

緩存能解決的問題

· 提升性能

絕大多數(shù)情況下，select 是出現(xiàn)性能問題最大的地方。一方面，select 會有很多像 join、group、order、like 等這樣豐富的語義，而這些語義是非常耗性能的；另一方面，大多 數(shù)應用都是讀多寫少，所以加劇了慢查詢的問題。

分布式系統(tǒng)中遠程調用也會耗很多性能，因為有網絡開銷，會導致整體的響應時間下降。為了挽救這樣的性能開銷，在業(yè)務允許的情況（不需要太實時的數(shù)據(jù)）下，使用緩存是非常必要的事情。

· 緩解數(shù)據(jù)庫壓力

當用戶請求增多時，數(shù)據(jù)庫的壓力將大大增加，通過緩存能夠大大降低數(shù)據(jù)庫的壓力。

緩存的適用場景

· 對于數(shù)據(jù)實時性要求不高

對于一些經常訪問但是很少改變的數(shù)據(jù)，讀明顯多于寫，適用緩存就很有必要。比如一些網站配置項。

· 對于性能要求高

比如一些秒殺活動場景。

緩存三種模式

一般來說，緩存有以下三種模式：

· Cache Aside 更新模式

· Read/Write Through 更新模式

· Write Behind Caching 更新模式

通俗一點來講就是，同時更新緩存和數(shù)據(jù)庫（Cache Aside 更新模式）；先更新緩存，緩存負責同步更新數(shù)據(jù)庫（Read/Write Through 更新模式）；先更新緩存，緩存定時異步更新數(shù)據(jù)庫（Write Behind Caching 更新模式）。這三種模式各有優(yōu)劣，可以根據(jù)業(yè)務場景選擇使用。

Cache Aside 更新模式

這是最常用的緩存模式了，具體的流程是：

· 失效：應用程序先從 cache 取數(shù)據(jù)，沒有得到，則從數(shù)據(jù)庫中取數(shù)據(jù)，成功后，放到緩存中。

· 命中：應用程序從 cache 中取數(shù)據(jù)，取到后返回。

· 更新：先把數(shù)據(jù)存到數(shù)據(jù)庫中，成功后，再讓緩存失效。

 

Cache Aside 更新模式流程圖

注意我們上面所提到的，緩存更新時先更新數(shù)據(jù)庫，然后在讓緩存失效。那么為什么不是直接更新緩存呢？這里有一些緩存更新的坑，我們需要避免入坑。
 
避坑指南一

先更新數(shù)據(jù)庫，再更新緩存。這種做法最大的問題就是兩個并發(fā)的寫操作導致臟數(shù)據(jù)。如下圖（以Redis和Mysql為例），兩個并發(fā)更新操作，數(shù)據(jù)庫先更新的反而后更新緩存，數(shù)據(jù)庫后更新的反而先更新緩存。這樣就會造成數(shù)據(jù)庫和緩存中的數(shù)據(jù)不一致，應用程序中讀取的都是臟數(shù)據(jù)。


 

 

 

兩個并發(fā)的寫操作導致臟數(shù)據(jù)
 
避坑指南二

先刪除緩存，再更新數(shù)據(jù)庫。這個邏輯是錯誤的，因為兩個并發(fā)的讀和寫操作導致臟數(shù)據(jù)。如下圖（以Redis和Mysql為例）。假設更新操作先刪除了緩存，此時正好有一個并發(fā)的讀操作，沒有命中緩存后從數(shù)據(jù)庫中取出老數(shù)據(jù)并且更新回緩存，這個時候更新操作也完成了數(shù)據(jù)庫更新。此時，數(shù)據(jù)庫和緩存中的數(shù)據(jù)不一致，應用程序中讀取的都是原來的數(shù)據(jù)（臟數(shù)據(jù)）。

 

 

 

兩個并發(fā)的讀和寫操作導致臟數(shù)據(jù)
 
避坑指南三

先更新數(shù)據(jù)庫，再刪除緩存。這種做法其實不能算是坑，在實際的系統(tǒng)中也推薦使用這種方式。但是這種方式理論上還是可能存在問題。如下圖（以Redis和Mysql為例），查詢操作沒有命中緩存，然后查詢出數(shù)據(jù)庫的老數(shù)據(jù)。此時有一個并發(fā)的更新操作，更新操作在讀操作之后更新了數(shù)據(jù)庫中的數(shù)據(jù)并且刪除了緩存中的數(shù)據(jù)。然而讀操作將從數(shù)據(jù)庫中讀取出的老數(shù)據(jù)更新回了緩存。這樣就會造成數(shù)據(jù)庫和緩存中的數(shù)據(jù)不一致，應用程序中讀取的都是原來的數(shù)據(jù)（臟數(shù)據(jù)）。

 

 


 

但是，仔細想一想，這種并發(fā)的概率極低。因為這個條件需要發(fā)生在讀緩存時緩存失效，而且有一個并發(fā)的寫操作。實際上數(shù)據(jù)庫的寫操作會比讀操作慢得多，而且還要加鎖，而讀操作必需在寫操作前進入數(shù)據(jù)庫操作，又要晚于寫操作更新緩存，所有這些條件都具備的概率并不大。但是為了避免這種極端情況造成臟數(shù)據(jù)所產生的影響，我們還是要為緩存設置過期時間。
 
Read/Write Through 更新模式


在上面的 Cache Aside 更新模式中，應用代碼需要維護兩個數(shù)據(jù)存儲，一個是緩存（Cache），一個是數(shù)據(jù)庫（Repository）。而在Read/Write Through 更新模式中，應用程序只需要維護緩存，數(shù)據(jù)庫的維護工作由緩存代理了。

 

 

 

Read Through

Read Through 模式就是在查詢操作中更新緩存，也就是說，當緩存失效的時候，Cache Aside 模式是由調用方負責把數(shù)據(jù)加載入緩存，而 Read Through 則用緩存服務自己來加載。

Write Through

Write Through 模式和 Read Through 相仿，不過是在更新數(shù)據(jù)時發(fā)生。當有數(shù)據(jù)更新的時候，如果沒有命中緩存，直接更新數(shù)據(jù)庫，然后返回。如果命中了緩存，則更新緩存，然后由緩存自己更新數(shù)據(jù)庫（這是一個同步操作）。

Write Behind Caching 更新模式

Write Behind Caching 更新模式就是在更新數(shù)據(jù)的時候，只更新緩存，不更新數(shù)據(jù)庫，而我們的緩存會異步地批量更新數(shù)據(jù)庫。這個設計的好處就是直接操作內存速度快。因為異步，Write Behind Caching 更新模式還可以合并對同一個數(shù)據(jù)的多次操作到數(shù)據(jù)庫，所以性能的提高是相當可觀的。

但其帶來的問題是，數(shù)據(jù)不是強一致性的，而且可能會丟失。另外，Write Behind Caching 更新模式實現(xiàn)邏輯比較復雜，因為它需要確認有哪些數(shù)據(jù)是被更新了的，哪些數(shù)據(jù)需要刷到持久層上。只有在緩存需要失效的時候，才會把它真正持久起來。

 

 

 

Write Behind Caching 更新模式

總結

三種緩存模式的優(yōu)缺點：

Cache Aside 更新模式實現(xiàn)起來比較簡單，但是需要維護兩個數(shù)據(jù)存儲，一個是緩存（Cache），一個是數(shù)據(jù)庫（Repository）。

Read/Write Through 更新模式只需要維護一個數(shù)據(jù)存儲（緩存），但是實現(xiàn)起來要復雜一些。

Write Behind Caching 更新模式和Read/Write Through 更新模式類似，區(qū)別是Write Behind Caching 更新模式的數(shù)據(jù)持久化操作是異步的，但是Read/Write Through 更新模式的數(shù)據(jù)持久化操作是同步的。優(yōu)點是直接操作內存速度快，多次操作可以合并持久化到數(shù)據(jù)庫。缺點是數(shù)據(jù)可能會丟失，例如系統(tǒng)斷電等。

緩存是通過犧牲強一致性來提高性能的。所以使用緩存提升性能，就是會有數(shù)據(jù)更新的延遲。這需要我們在設計時結合業(yè)務仔細思考是否適合用緩存。然后緩存一定要設置過期時間，這個時間太短太長都不好，太短的話請求可能會比較多的落到數(shù)據(jù)庫上，這也意味著失去了緩存的優(yōu)勢。太長的話緩存中的臟數(shù)據(jù)會使系統(tǒng)長時間處于一個延遲的狀態(tài)，而且系統(tǒng)中長時間沒有人訪問的數(shù)據(jù)一直存在內存中不過期，浪費內存。