《躍遷：從技術到管理的矽谷路徑》讀書筆記
前一段時間把這本書看完了，雖然沒啥技術方面的描述，但是看完這本書還是有點收穫的，記錄一些我有所獲的東西。
一、冪等的實現與常見問題
冪等的定義：多次執行所產生的影響均與一次執行的影響相同。那麼如何實現冪等呢？簡而言之，你需要一個去重機制。關於這一點有很多不同的實現方法，但是有兩個很關鍵的因素：
a)第一個因素是冪等令牌。客戶端與伺服器通過什麼方式來識別，這實際上是同一個請求或是同一個請求的多次嘗試。這往往需要雙方有一個既定的協議，比如賬單號或者交易令牌這種在同一個請求上具備唯一標識的元素。這種元素通常由客戶端生成。
b)第二個因素是確保唯一性。伺服器端用什麼機制去確保同一個請求一定不會被處理兩次？最常用的做法是利用資料庫。比如把冪等令牌所在的資料庫表的列作為唯一性索引，這樣，當你試圖儲存兩個含有同樣令牌的請求時，必定有一個會報錯。這樣做需要注意，簡單的讀檢查並不一定成功，因為讀與寫會有競爭條件，因此還是有可能出錯。
一個系統能正確處理和實現上面的兩個要素，基本就達到了冪等的需求。現實系統中常見的問題有：
1)冪等令牌什麼時候產生，怎樣產生？
2)令牌有沒有被誤刪的可能（比如一個支付請求中使用了，然後因為資料庫回滾等原因被刪除了）
3)各種競爭條件
4)對請求重試的處理
一個常見的辦法是，區分正在處理的請求、處理成功和處理失敗的請求。這樣，當客戶端重試的時候，就會根據情況直接返回或者再次處理。
5)一個系統中需要多層冪等（A-->B-->C-->.....鏈路的冪等性）
二、 API設計原則
1.保證API Restful的程式是100%，restful的核心是所有的行為和介面都應該是相應resource上的增刪改查（CRUD）操作。
2.在請求和響應中，應該儘可能地保持引數的結構化。如果是一個雜湊(hash)，就傳一個雜湊(不要傳hash.to_string)。API的序列化和反序列化機制會將其自動序列化成字串，多語言之間的API通常都是在序列化合反序列化機制中完成不同語言型別的轉換的。
3.有關鑑權和安全的考慮，應該始終放在首位。保證對特定的使用者永遠只暴露相關的介面和許可權。鑑權可以使用證書和白名單，也可以通過Token或Session/Cookie等方式處理。此外，所有API層的日誌，都要保證不記錄任何敏感資訊。
4.API本身應該是與客戶端無關的。所有與客戶端無關的計算和處理，要儘可能在伺服器端統一進行，以提高效能和一致性。
5.儘可能讓API是冪等的。（具體的實現參考具體的應用場景）
評估一個API框架，可以從這幾方面考慮：對訪問許可權的統一控制；對自動測試的支援；對請求和響應的格式以及序列化和反序列化的支援；對日誌和日誌過濾的支援；對自動文件生成的支援；對架構和效能的影響。
三、職業規劃自問
1.你的個人價值觀是什麼，你最在意什麼？
2.你的長期願景是什麼，五年甚至十年後，你希望自己成為什麼樣的人？
3.為了達到目標，你還需要掌握哪些技能或者經驗？在短期內發展什麼技能可能讓你走的更遠？
4.想實現職業夢想，或在工作中取得成功，你還需要做些什麼，具備哪些技能技能？哪些技能對你來說不是必需的，但是會有很大好處？
5.你的優勢和長處是什麼（合作性/獨立思考/行動快速/良好的產品思維等）你現在的日常工作能否讓你展示長處，如果能又是如何展示的？
6.你覺得自己比別人在哪些方面做得好，能不能舉出具體的例子？
四、RabbitMQ與Kafka的對比
1.Kafka是分散式的訊息系統，它的高吞吐量主要取決於是否有一個比較大的伺服器群，如果只是很小規模的系統，Kafka可能沒法完全施展它的優勢。
2.Kafka是以producer為中心的，因此對於consumer能否按需獲得訊息並不關心。而RabbitMQ是以broke為中心的，因此會很大程度上考慮consumer的接收能力。這意味著，如果consumer基於不同的機器或者伺服器端，Kafka有絕對優勢，RabbitMQ只能處理同類的consumer伺服器群。
3.Kafka的訊息本質上就是一個日誌，它可以保證所有的訊息都是有序的，但是不允許對訊息的順序進行任何改動，與之相反，RabbitMQ從某種意義上來說為每個佇列都維護了訊息的邏輯拷貝。
4.Kafka中的每一條訊息其實都沒有id的，由於全是位元組流，因此訊息是通過一個offset來標識的。而RabbitMQ中的每條訊息都是有型別也有標識的。這樣，一些傳遞失敗的訊息就可以在未來的某個時刻重新被投送和處理，這樣的訊息就叫做“Dead Letter”。
兩個系統的設計理念，RabbitMQ是完全基於AMQP的訊息代理，而Kafka是一個更通用的訊息系統，很大程度上還反映了基於日誌服務的一些思想。總體來說，Kafka支援高流量，但是訊息就被當做簡單有序的日誌，側重於共享，不能實現基於逐條訊息的處理。RabbitMQ支援中小流量，但是在訊息處理上有很大的靈活性。
-------------------------------------------------------------------分割線---------------------------------------------------------------------
其實看完這本書收穫的更多是一些管理層的意識問題和個人成長的一些思考，因為我本人是公司第一個測試，然後招來的測試組長調崗了，公司就把我推了上來。做這個管理崗也快一年了，深知自己不是一個合格的管理者。其中性格佔了很大的因素以及個人還是願意做技術多一點(其實是不怎麼擅長和人打交道，╮(╯▽╰)╭)。看書的名字就知道，這更多的是針對從技術崗轉到管理崗的人，所以有這情況的人，倒是推薦把這本書讀讀。關於個人成長的一些思考，就不一一表述成文字了。
此時的上海真冷啊。emmm，擡頭一看，外面飄著雪，瑟瑟發抖的我邊打字邊搓手.....
___日拱一卒，不期速成