【資訊軟體知識】「鎖」的兩極化，樂觀與悲觀
這次會分享關於「鎖」的主題除了工作上遇到這樣的情境之外，也發現到其實軟體技術大部分跟我們生活情境息息相關，覺得非常有趣，因此嘗試將艱澀難懂的技術化為淺顯易懂的圖文知識來幫助大家快速理解，除了應用在工作上，或許對於生活過程中遇到的一些問題也能得到一些啟發。
此篇章主要著重於觀念的分享，並不會深入探討實作的細節，相信只要觀念通了，對於技術實作的道路上一定會非常順暢，好吧！廢話不多說，趕快來介紹一下樂觀鎖與悲觀鎖的基本觀念。
情境
軟體開發的過程中想必我們開會過程中常常會聽到以下的關鍵字句：
- 併發問題就應該用樂觀鎖啊！
- 最安全的併發正確性應該用悲觀鎖吧！
- Scale Out的服務怎麼保證正確呢？
- 啊！雙十節要到了，如何確保客戶的訂單與商品數量是正確的又能兼顧效能？
- 併發問題就應該用樂觀鎖啊！
- 最安全的併發正確性應該用悲觀鎖吧！
- Scale Out的服務怎麼保證正確呢？
- 啊！雙十節要到了，如何確保客戶的訂單與商品數量是正確的又能兼顧效能？
以上的問題都圍繞在效能、正確性， 而其中最關鍵的就是「鎖」， 雖然「鎖」難免會造成效能的下降， 但這點不足之處對於現階段的群集架構之下， 已經能夠透過橫向擴展的方式進行補足， 因此「鎖」的技術值得我們好好認識一番！
悲觀鎖(Pessimistic Lock) 😭
就如同字面上的意思， 對任何的事物都很悲觀， 而這種情緒之下的處理方式就是盡量鎖住整個資源， 保證整體一致性之後再釋放， 雖然安全但效能下降程度非常的高。
以生活化的例子來說， 當我們要去餐廳慶祝一下的時候， 通常就兩種作法， 不是預訂就是現場候位， 那麼較悲觀的人可能會事先安排， 因此會進行訂位的動作， 那麼一旦訂位之後， 該位置到某個時段就等於是被「鎖」上， 直到我們用完餐之後才釋放， 這樣的情境下確保我們能正確的慶祝用餐， 但對於資源使用上來說就相對耗費了， 尤其當我們發生非預期狀況之下無法到場時， 原本餐廳能夠服務到更多客人， 卻因為我們的「鎖」而導致服務客人的量減少了， 餐廳也少賺了一些客人的消費金額。
優點
- 保證「鎖」上的資源能夠完整處理操作後再釋放。
缺點
- 「鎖」的粒度太大導致資源的浪費。
樂觀鎖(Optimistic Lock) 😀
先做就對了， 有衝突再解決…。
一樣以餐廳為例， 這次就變成現場候位的狀況， 不採取預訂方式， 有位置再吃， 大不了下個時段再來， 這樣對於餐廳端來說， 資源閒置的狀況減少了， 每一桌吃完就服務下一桌， 以軟體技術語言的角度來說就是，先提交若「⚔️衝突」則下次提交。
上面有三個關鍵字分別是「先提交」、「衝突」、「下次提交」， 很暴力簡單的作法卻很有效， 最關鍵的就是「⚔️衝突」的偵測， 如何識別「⚔️衝突」就是相當重要的一環了。
其實偵測「⚔️衝突」的原理非常簡單， 通常最簡易的作法就是壓上一個版本號， 假若針對目標進行異動時， 發現版本號已經被異動了， 就視為「⚔️衝突」， 再更新資料到記憶體並重新進行一次操作即可。
優點
- 資源相對悲觀鎖能夠較有效的被善用。
缺點
- 併發量越高， 可能發生衝突的機率越高。
- 通常是人為實現的， 因此使用時要非常小心控制的欄位。
- 通常是人為實現的， 因此使用時要非常小心控制的欄位。
結語
「🔑 鎖」的概念非常的有趣， 結合到現實面也能夠藉此改善流程及效率， 大幅減少資源的浪費， 降低成本， 在雲端時代中， 軟體也漸趨複雜， 隨著無國界的發展， 一套優質的軟體勢必會服務來自世界各地的使用者， 然而當使用量倍增時， 也勢必面臨到橫向擴展與平行處理的技術， 但在這之間如何維持正確性與兼顧效能， 就取決於我們怎麼使用這把「🔑 鎖」囉。
除非有非常強烈的一致性需求才使用悲觀鎖， 否則一般的情境下樂觀鎖基本上都能夠通用。
每一項技術的背後都有其優缺點， 並非單一項就能通吃， 因此若我們能夠多認識一些技術背後的原理與優缺點， 相信遇到狀況時就能夠隨時因應變化， 端出最適用的技術應對， 如此一來才能夠打造出穩定可靠的系統軟體。
喜歡撰寫文章的你，不妨來了解一下：
歡迎加入一起練習寫作，賺取知識，累積財富！
即將進入廣告，捲動後可繼續閱讀
為什麼會看到廣告
118會員
266內容數
哈囉，我是阿Han，是一位 👩💻 軟體研發工程師，喜歡閱讀、學習、撰寫文章及教學，擅長以圖代文，化繁為簡，除了幫助自己釐清思路之外，也希望藉由圖解的方式幫助大家共同學習，甚至手把手帶您設計出高品質的軟體產品。
留言0
查看全部
你可能也想看
Google News 追蹤
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
在交易裡面，我們需要理解走勢的為什麼。深深的進入去理解。理解走勢的第一步，然後是走勢的第二步，走勢的第三步，第四步，第五步，第六步，然後到走勢未來會去的那一個最後步。就是去看見。
和匱乏比起來，我們較難因應豐盛。凡事順遂的時候要嚴守紀律，在心理上拋去身外之物十分困難，但這正是一個人最需要紀律的時候。
建立一個系統，其中不管誰倒下去，都不會拖累其他人，持續不斷的失敗，有助於保存整個系統。
為了穩定而設法取得穩定，在經濟和外交上是一種冤大頭遊戲。(銀行大到不能倒的地位，詐
人再有理性，在壓力面前都會被情緒拉扯。
尤其是生活是一人負擔，又面對不穩定的環境。怎樣都會想找個支柱…不過經過這麼憂慮的時段後，我可以說自己一直被守護著。至少我這個星期三天就見了近10份工。而在找工時候，都有“信息”表達8號之前就能有好消息，把兔仔帶回，否則上班就難了。也確實之後兔仔沒得獎需要帶回
事情起因源自某個清晨收到友人的訊息。
「我可能需要封鎖你，因為你未來會造成我的困擾。」語畢補上祝福及感謝的話語，沒等待我回覆便按下了封鎖鍵，看到訊息當下滿滿的錯愕，難過於對方尚未聽完我的想法便單方面執行封鎖，明明前晚還在愉快聊天毫無衝突徵兆，又矛盾於明明不是第一次面對被友人封鎖。
這篇文章探討了在軟體開發中的技術債可能來自哪些原因，以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇，提供了對於技術債的思考與建議，針對開發人員在需要做出無奈的技術決策時，提供了一些建議。此外，還提供了一些在做出技術決策時的方法，如保留抽象層和避免vendor lock-in。
人們在設立計畫時，都講求精確、預測與邏輯；然而，常見的卻是：情緒影響、不如預期、判斷失準。與其預測不確定的事件，不如專注理解恆常的行為，才能獲得最大的滿足與成就。＊判斷行為模式，而非事件本身。＊要想活得幸福，就該管理期望。＊不確定性，是商業領域最強大的力量。
物件導向設計的一個重點就是封裝，這有很多層面上的意義，但基本上就是控制物件的成員變數和方法的存取權。物件導向的封裝還跟繼承機制有關，這使得有一些時候我們逼不得已必須把函式定義在類別上，這種做法使得物件的功能變得難以拆解。封裝應該是模組的職責，並不需要再給物件相同的能力。
一般的模組系統就是把相
對於將「堅持到底」奉為圭臬的華人而言，我們渴望成功、不想輸，甚至沒人教我們如何「失敗」。這篇文章整合了科技公司和人生的關係，以及運用貝佐斯的遺憾最小化框架，設想我們如何面對重大抉擇。
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
在交易裡面，我們需要理解走勢的為什麼。深深的進入去理解。理解走勢的第一步，然後是走勢的第二步，走勢的第三步，第四步，第五步，第六步，然後到走勢未來會去的那一個最後步。就是去看見。
和匱乏比起來，我們較難因應豐盛。凡事順遂的時候要嚴守紀律，在心理上拋去身外之物十分困難，但這正是一個人最需要紀律的時候。
建立一個系統，其中不管誰倒下去，都不會拖累其他人，持續不斷的失敗，有助於保存整個系統。
為了穩定而設法取得穩定，在經濟和外交上是一種冤大頭遊戲。(銀行大到不能倒的地位，詐
人再有理性，在壓力面前都會被情緒拉扯。
尤其是生活是一人負擔，又面對不穩定的環境。怎樣都會想找個支柱…不過經過這麼憂慮的時段後，我可以說自己一直被守護著。至少我這個星期三天就見了近10份工。而在找工時候，都有“信息”表達8號之前就能有好消息，把兔仔帶回，否則上班就難了。也確實之後兔仔沒得獎需要帶回
事情起因源自某個清晨收到友人的訊息。
「我可能需要封鎖你，因為你未來會造成我的困擾。」語畢補上祝福及感謝的話語，沒等待我回覆便按下了封鎖鍵，看到訊息當下滿滿的錯愕，難過於對方尚未聽完我的想法便單方面執行封鎖，明明前晚還在愉快聊天毫無衝突徵兆，又矛盾於明明不是第一次面對被友人封鎖。
這篇文章探討了在軟體開發中的技術債可能來自哪些原因，以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇，提供了對於技術債的思考與建議，針對開發人員在需要做出無奈的技術決策時，提供了一些建議。此外，還提供了一些在做出技術決策時的方法，如保留抽象層和避免vendor lock-in。
人們在設立計畫時，都講求精確、預測與邏輯；然而，常見的卻是：情緒影響、不如預期、判斷失準。與其預測不確定的事件，不如專注理解恆常的行為，才能獲得最大的滿足與成就。＊判斷行為模式，而非事件本身。＊要想活得幸福，就該管理期望。＊不確定性，是商業領域最強大的力量。
物件導向設計的一個重點就是封裝，這有很多層面上的意義，但基本上就是控制物件的成員變數和方法的存取權。物件導向的封裝還跟繼承機制有關，這使得有一些時候我們逼不得已必須把函式定義在類別上，這種做法使得物件的功能變得難以拆解。封裝應該是模組的職責，並不需要再給物件相同的能力。
一般的模組系統就是把相
對於將「堅持到底」奉為圭臬的華人而言，我們渴望成功、不想輸，甚至沒人教我們如何「失敗」。這篇文章整合了科技公司和人生的關係，以及運用貝佐斯的遺憾最小化框架，設想我們如何面對重大抉擇。