互聯網 - 大數據

文章出處
分布式系統的服務注冊與發現解決的場景沒有什么新奇的，我們一直都在用，可以用通俗點的例子解釋下。
中介市場
以找工作為例子，在沒有互聯網的時候，吃瓜群眾想找買房子去哪呢？很明顯是各種中介。因為人海茫茫，誰知道哪個房東要賣房呢？明顯需要一個雙方都知道的中間場所。 找房子的過來，賣房子的也過來，能對接上。
服務注冊
在跨進程通信時，這叫服務注冊，一個進程A想要調用B集群的服務，B集群的機器在哪里，找服務注冊中心，注冊中心告訴你這個B服務的調用IP是啥。在麻瓜的世界，這個叫中介。這就像一個人，要買西湖區綠城誠園（服務）的房子，而那個中介提供了所有有這個房源的房東（IP地址）。
服務路由與負載均衡
有了房子還不夠，合格的中介應該能幫買家篩選一下這個小區的房源，哪些比較合適，殘次品就算了。 所以服務中間件又有一定的負載均衡能力和路由能力，比如我要找同一個機房的服務，不要跨機房調用，給我這個機房內這個服務注冊的的IP地址。
健康檢查
中介通常還有附加的功能，例如維護招聘信息的時效性，當中介知道招聘信息已經無效了，會把這個信息去掉，這個過程在服務的世界里叫健康檢查。 招聘信息的去掉也分兩種方式：1.用人方主動告知中介；2.求職方找中介后聯系用人單位發現信息過時了，告知中介。
第一種方式，叫服務優雅下線，一個應用知道自己要shutdown了，主動通知注冊中心，我要下線了，把我的IP從服務列表里摘掉吧。
第二種方式，調用方在調用一個無效服務后一直超時，此時服務框架有義務將這個IP地址的服務暫時屏蔽掉，將調用請求路由到集群的其他機器。
分布式
當一個中介在當地打出知名度后，可能上門來的需求越來越來多，一個分店滿足不了了，很明顯要開始擴張了。由于投資人給我們投了錢，現在荷包比較充裕，讓我們一口氣擴到三家店吧。
店多了，但我們的房源名單是共享的，所有分店都有一份，很明顯我們要保持各家分店的名單是最新的，當一個店里有了新的房源，不但要更新自家店鋪的數據庫，還要更新另外三家的。這就是注冊在多個數據中心或機房的服務遇到的問題，要保持一致性。
面對這個局面，我們先要分析下我們對各個門店房源名單的不一致性能容忍到什么程度。 在一家店A更新的了自己的房源為已售后， 另一家店B更新慢了，此時有客戶上門來看這個房源，在上門看房后被告知房源已售后能否簡單的對客戶說句sorry， 而不被扔西紅柿呢？
最終一致性
如果能接受這個延遲（銷售經理臉皮厚），那么恭喜了，我們可以使用最終一致性模型來更新這條數據，即一家店更新后，其他店可能不能馬上保證能得到這條數據，但一定有保證經過一段時間后肯定能得到這條數據，代價是銷售經理被罵和損失門店信譽。
強一致性
如果銷售經理實在接受不了天天被罵，強烈要求別的店更新了房源數據一定要告訴他，那么我們就必須使用強一致性模型了。 在這個模型下，每家門店的數據更新，要么不更新，要么全部更新。怎么做呢？ 我們需要一個協調點， 在三個門店某家有更新需求時告訴這個協調代理，這個協調代理告知所有參與者需要進行提交，各門店嚴陣以待，開始準備提交并告知協調代理已經準備好了；協調代理在接收到所有三家店的ready信號后，告知三家代理可以更新了，三家代理的秘書把名單更新好后告知協調代理已經完成了，這時所有的數據更新操作結束了。反之，如果某家門店的秘書在更新名單時發現鋼筆沒水了，這次操作失敗了，那么另兩家這次操作也要取消掉。
以上是將一份數據分布化后會遇到的一系列挑戰。
Google IO 2009年有一則關于此方面的分享<數據中心間的事務>

http://snarfed.org/transactions_across_datacenters_io.html
https://www.youtube.com/watch?v=srOgpXECblk

---

文章來自微信平臺「麥芽面包」
微信公眾號「darkjune_think」
轉載請注明。
如果覺得文章有趣，可以長按圖片識別二維碼關注我。

文章出處
前言
用python的AIML包很容易就能寫一個人工智能聊天機器人。 AIML是Artificial Intelligence Markup Language的簡寫， 但它只是一個簡單的XML。 下面的代碼例子會帶你寫一個你自己的Python人工智能聊天機器人。
什么是AIML？
AIML是Richard Wallace開發的。 他開發了一個叫A.L.I.C.E（Artificial Linguistics Internet Computer Entity）的機器人并且贏了幾個人工智能的獎項。 有趣的是， 其中一個圖靈測試是讓一個人在文本界面跟一個機器人聊幾分鐘，看看人們是否認為它是個人類。 AIML是一種定義了匹配模式和決定響應的規則的一種XML。
要看完整的AIML入門，可以看一下 Alice Bot's AIML Primer.你可以在AIML wiki頁學更多關于AIML的知識并知道它能做什么。 我們先寫一些AIML文件并用Python給它一點生命。
寫標準啟動文件
標準是寫一個叫std-startup.xml的啟動文件作為載入AIML文件的主入口點。 這個例子里我們會寫一個可以匹配一個模式并做一個動作的基本文件。 我們想要匹配模式load aiml b， 然后讓它載入我們的aiml大腦。我們會花一分鐘寫一個basic_chat aiml文件。
<aiml version="1.0.1" encoding="UTF-8">
<!-- std-startup.xml -->
<!-- Category is an atomic AIML unit -->
<category>
<!-- Pattern to match in user input -->
<!-- If user enters "LOAD AIML B" -->
<pattern>LOAD AIML B</pattern>
<!-- Template is the response to the pattern -->
<!-- This learn an aiml file -->
<template>
<learn>basic_chat.aiml</learn>
<!-- You can add more aiml files here -->
<!--<learn>more_aiml.aiml</learn>-->
</template>
</category>
</aiml>
寫AIML文件
上面我們寫了一個只處理一種模式的AIML文件，load aiml b。當我們輸入那條命令給機器人，它會加載basic_chat.aiml。當我們沒寫這個文件的時候是不會工作的。這里是你可以放到basic_chat.aiml的內容。我們會匹配兩個基本模式和響應。
<aiml version="1.0.1" encoding="UTF-8">
<!-- basic_chat.aiml -->
<category>
<pattern>HELLO</pattern>
<template>
Well, hello!
</template>
</category>
<category>
<pattern>WHAT ARE YOU</pattern>
<template>
I'm a bot, silly!
</template>
</category>
</aiml>
隨機回復
我們也可以加一些隨機回復。這條在它收到一個以“One time I"開始的消息時會隨機回復。 *是一個占位符代表能匹配任何字符。
<category>
<pattern>ONE TIME I *</pattern>
<template>
<random>
<li>Go on.</li>
<li>How old are you?</li>
<li>Be more specific.</li>
<li>I did not know that.</li>
<li>Are you telling the truth?</li>
<li>I don't know what that means.</li>
<li>Try to tell me that another way.</li>
<li>Are you talking about an animal, vegetable or mineral?</li>
<li>What is it?</li>
</random>
</template>
</category>
用現成的AIML文件
寫自己的AIML文件很有意思，但會是個很大的工作量。我想它需要大約一萬的模式才能看起來真實一點。幸好，ALICE基金提供很多免費的AIML文件。可以在Alice Bot網站看看AIML文件。那有個叫std-65-percent.xml文件包括了常規65%的場景。那也有一個可以讓你玩21點（BlackJack）的機器人。
寫Python
到目前為止，所有的東西都是AIML XML文件。這些是可以構造機器人大腦的重要部分，但這些只是一些信息。機器人需要變活。你需要用一些語言來實現AIML規范，但一些好心人已經用Python做了。
先用pip裝aiml包。
pip install aiml
記住aiml包只能在Python 2下用。 Python 3可以用GitHub上的Py3kAiml替代。
簡單Python程序
這是我們能啟動的最簡單的程序。它建一個aiml對象，學習啟動文件，并加載剩下的aiml文件。這之后，就可以聊天了，然后我們進入一個無限循環并持續讓用戶輸入消息。你需要輸入一個機器人能識別的模式。模式識別依賴于你之前加載的AIML文件。
我們寫個單獨的啟動文件，這樣我們可以不用動程序源碼加載更多的aiml文件。我們可以在啟動xml文件加更多的文件來學習。
import aiml
# Create the kernel and learn AIML files
kernel = aiml.Kernel()
kernel.learn("std-startup.xml")
kernel.respond("load aiml b")
# Press CTRL-C to break this loop
while True:
print kernel.respond(raw_input("Enter your message >> "))
加速大腦啟動
當你有很多AIML文件，這需要學很長時間。這就要靠機器人大腦文件了。在機器人學習了所有的AIML文件后并可以直接把大腦存到一個文件里，這樣在下次啟動時就可以直接加速。
import aiml
import os
kernel = aiml.Kernel()
if os.path.isfile("bot_brain.brn"):
kernel.bootstrap(brainFile = "bot_brain.brn")
else:
kernel.bootstrap(learnFiles = "std-startup.xml", commands = "load aiml b")
kernel.saveBrain("bot_brain.brn")
# kernel now ready for use
while True:
print kernel.respond(raw_input("Enter your message >> "))
運行中重載AIML
你可以在運行時發重載消息給機器人來重載AIML文件。記住如果你使用了之前寫的大腦方法，重載不會節省剛對大腦做的改動。你需要刪除大腦文件一遍下次啟動時可以重建，或者你需要改代碼讓機器人在下次重載后的一個時間點來保存大腦。看下節寫Python命令給機器人。
load aiml b
加Python命令
如果你要給你的機器人加一些命令來運行Python函數，那你需要捕獲機器人的輸入信息并在發給kernel.respond()前處理它。上個例子我們從raw_input得到了用戶的輸入。我們可以從很多地方得到輸入。比如一個TCP socket，或一個語音轉文本的源。在它發給AIML前處理它。你需要在某些消息時跳過AIML。
while True:
message = raw_input("Enter your message to the bot: ")
if message == "quit":
exit()
elif message == "save":
kernel.saveBrain("bot_brain.brn")
else:
bot_response = kernel.respond(message)
# Do something with bot_response
會話和斷言
通過一個會話，AIML可以區分不同人的不同的對話。例如，如果一個人告訴機器人她的名字是Alice，另一個人告訴機器人他的名字是Bob，機器人可以區分他們。為了指定你在用哪個會話你可以傳給respond()第二個參數。
sessionId = 12345
kernel.respond(raw_input(">>>"), sessionId)
這樣每個客戶都有個性化的聊天，很好。你可以生成你自己的session id（會話id）并跟蹤他們。記住保存大腦文件并不會保存所有會話值。
sessionId = 12345
# Get session info as dictionary. Contains the input
# and output history as well as any predicates known
sessionData = kernel.getSessionData(sessionId)
# Each session ID needs to be a unique value
# The predicate name is the name of something/someone
# that the bot knows about in your session with the bot
# The bot might know you as "Billy" and that your "dog" is named "Brandy"
kernel.setPredicate("dog", "Brandy", sessionId)
clients_dogs_name = kernel.getPredicate("dog", sessionId)
kernel.setBotPredicate("hometown", "127.0.0.1")
bot_hometown = kernel.getBotPredicate("hometown")
在AIML中我們可以在模板中設置response來設置斷言。
<aiml version="1.0.1" encoding="UTF-8">
<category>
<pattern>MY DOGS NAME IS *</pattern>
<template>
That is interesting that you have a dog named <set name="dog"><star/></set>
</template>
</category>
<category>
<pattern>WHAT IS MY DOGS NAME</pattern>
<template>
Your dog's name is <get name="dog"/>.
</template>
</category>
</aiml>
用上面的AIML你可以告訴機器人：
My dogs name is Max
然后機器人會回復：
That is interesting that you have a dog named Max
如果你問：
What is my dogs name?
機器人會回答：
Your dog's name is Max.
更多資料
AIML Tag Reference Table

原文：http://www.devdungeon.com/content/ai-chat-bot-python-aiml

---

本文來自微信平臺「麥芽面包」
微信公眾號「darkjune_think」轉載請注明。
微信掃一掃關注公眾號。

文章出處
1月6號，像往常一樣，在工作的間隙，我打開手機上的今日頭條。點開了其中一個新聞，發現進去后頁面提示網絡不給力，請稍后重試。前兩天我的4G網絡上不去，折騰了半天正要打聯通客服咒罵，在IVR語音提示時才發現已經欠費了。但現在話費可是本月剛充的啊，何況現在連的是公司的WIFI，難道公司網絡有問題？這時通知中心彈出了其他應用的提醒，貌似其他應用是正常的。那么就是被頭條的提示的忽悠了，任何錯誤提示給用戶的都是你的網絡不給力。
果不其然，稍后其他的新聞看到頭條的服務掛了許久的消息。
SRE - Site Reliability Engineering, Google提出的一個概念，綜合了Google多年運維大規模服務器集群的經驗演變出的一個職位。其目的就是為了最大限度的保障Google服務的可靠性，其演進方向是從運維工程師向開發工程師邊界的擴展，要求運維工程師以軟件工程的思路解決大規模運維的問題，用工具而不是人力來解決不斷擴大的服務器集群對管理的需求。
如何保障網站可靠性，通常是在運維，基礎架構，系統管理員的范疇。關注業務開發的軟件工程師不關心這個，他們要忙著應付PD的最后期限，讓飛速發展的平臺支撐上層的業務需求。
在云計算基礎設施還沒成型時，互聯網公司都會有個運維團隊負責搞各種各樣跟系統有關的活。在企業發展的不同階段，這只團隊可能會忙著提采購需求給財務；評估系統容量，要多少IOPS的SSD硬盤， 多大的內存才能滿足應用需求；寫各種各樣的發布腳本，將開發提供的war包（如果是java應用）批量分發服務器的目錄上并啟動tomcat；搭LVS為機房入口提供熱備的負載均衡設施；用keeplived提供VIP去單點，為后端服務提供故障遷移能力；跑到機房去為機器上架，布設機架網線，甚至配合容災演練去拔網線測試；還要制定線上應用的發布規范，保證成千上萬的應用能按照統一的規范發布，秉著約定優于配置的原則，讓整個公司的人可以不加思索的找到應用的啟動腳本，log目錄；新機器上線需要初始化系統，隨著虛擬化大潮物理機都要切分成虛擬機才交付給開發部門；出了個緊急安全漏洞得給系統或應用打補丁；線上生產機的權限要管好，別被黑客提權出了簍子；往往可能還要客串一把網絡工程師粗排一下千奇百怪的運營商到IDC網絡丟包，緩慢問題。
以上還不是最累的，運維團隊還要為線上故障排查負責，軟件工程師半夜只會收到自己應用的報警，運維團隊是要接受自己管理全部應用的報警的，出了問題往往開發和運維都要一起排查，一個高速發展的公司都會經歷那么一段故障頻發的苦逼日子，運維成天到晚在忙著救火。
由于運維與開發部門不在一個部門，且各自關注的目標不同，伴隨著長期的沖突和博弈。開發只關心功能上線，運維部門關心應用穩定運行。從前，開發可以快樂的自己登錄到線上機器上發布代碼，scp個本地的war包過去，就跑起來了；自從xxx日出了故障導致網站宕機1小時，錯過了促銷的黃金時間后，發布就被套上了流程的管控，層層審批，就是為了減少發布的次數，因為理論上發的越多，越容易出問題，一個一年只發布一次的系統，基本沒什么可能出問題。
Devops理念是伴著云計算理念出來的，在amazon的云計算成熟后，以上說的傳統運維已經可以通過買云服務實現了，不用自己采購機器，買個EC2，數據庫服務也可以直接買RDS，對象存儲用S3, Load Balancing也可以買。開發人員自助在上面操作一下，部署上自己的應用就可以提供服務了，買個域名將DNS直接A記錄指向服務器就行了。可以說是中小公司的福音，互聯網創業不用考慮太多的服務器問題了，把有限的人力投入到至關重要的業務功能開發商，其他的服務器運維工作交給專業的云計算公司來做。
網絡視頻租賃商Netflix就是個知名的例子，其服務都運行在AWS上。由于其多年跑在云上的分布式經驗，還在github上開源了不少分布式處理的組件，回饋了社區。其遷移的路程也算長的，從2008年到2015年，7年，完成了全部應用到AWS的遷移。他們認為AWS提供了更可靠的服務。
有遷入也有遷出的，著名的網絡存儲提供商Dropbox由于嫌AWS太貴，將自家服務重新移到了自家機房運維。
很有意思不是嗎？
那么
想體驗自己的服務被上億人使用的感覺嗎？
想參與每年雙11的技術狂歡嗎？
想了解一線大廠的分布式技術如何抗住海量流量嗎？
阿里集團客戶體驗事業群旨在建立更高的客戶服務標準，讓客戶在阿里享受到最“爽”的服務，讓“客戶第一”成為阿里的百年口碑。
CRM產品技術部作為支撐全網服務的產品技術團隊，希望通過我們的產品、數據、技術去提升阿里集團服務幾億客戶的能力，提升全網客戶體驗。這里是最能聽到“炮火”的地方，可以通過我們的努力，最直接的看到產品的改善。
在這里可以接觸第一手的大數據。
這是一個以用戶為中心的多角色無邊界團隊，一個有夢想的歡樂團隊，一個能近距離感受用戶溫度的團隊。無論你是何種角色，只要站在用戶的角度思考問題，你的意見都有機會被采納實施，去產品中落地。
關于用戶體驗的經驗和妙想會得到重視，可以站在集團層面，推動與解決難以落地的用戶問題。
如果你來到我們團隊，那么你的職責可能包括但不限于：

負責Alibaba客戶服務相關的產品研發

深入發掘和分析業務需求，撰寫技術方案和系統設計

核心代碼編寫、指導和培訓工程師、不斷進行系統優化

參與或領導跨團隊的研發項目

崗位要求：

JAVA基礎扎實，理解io、多線程、集合等基礎框架，對JVM原理有一定的了解；

3年及以上使用JAVA開發的經驗，對于你用過的開源框架，能了解到它的原理和機制；對Spring,ibatis,struts等開源框架熟悉；

熟悉分布式系統的設計和應用，熟悉分布式、緩存、消息等機制；能對分布式常用技術進行合理應用，解決問題；

掌握多線程及高性能的設計與編碼及性能調優；有高并發應用開發經驗；

掌握Linux 操作系統和大型數據庫（Oracle、MySql）；對sql優化有豐富的經驗；

學習能力強，適應能力好；具備耐心/細心的品質；

喜歡去看及嘗試最新的技術，追求編寫優雅的代碼，從技術趨勢和思路上能影響技術團隊

簡歷盡情發送到kunrong.zkr@alibaba-inc.com

文章出處

原文在http://rerun.me/2014/10/06/akka-notes-actorsystem-in-progress/

像我們前面看到的，我們可以用ActorSystem的actorof方法來創建Actor。其實你可以用ActorSystem做更多事。我們可以先看下Configuration和Scheduling。
讓我們先看下ActorSystem 的方法。
1. 配置管理
還記得前一篇我們用application.conf文件來配置我們的日志級別嗎？這個文件跟java里用的.properties文件很像。我們馬上會看到我們如何用這個配置文件來自定義我們的dispatchers（分發器）, mailboxes（郵箱）等。(我還沒好好介紹typesafe config的神奇， 請自己去看一些例子來領略吧)
所以，當我們不指定任何配置用ActorSystem對象的apply方法創建ActorSystem時，他會自動在classpath的根路徑上加載application.conf,application.json和application.properties。
所以，

val system=ActorSystem("UniversityMessagingSystem")

等價于

val system=ActorSystem("UniversityMessagingSystem", ConfigFactory.load())

想驗證這個參數， 只要看下ActorSystem.scala的apply方法

 def apply(name: String, config: Option[Config] = None, classLoader: Option[ClassLoader] = None, defaultExecutionContext: Option[ExecutionContext] = None): ActorSystem = {
val cl = classLoader.getOrElse(findClassLoader())
val appConfig = config.getOrElse(ConfigFactory.load(cl))
new ActorSystemImpl(name, appConfig, cl, defaultExecutionContext).start()
}

A. 覆蓋缺省的配置
如果你不想使用application.conf(例如在testcase中)或者你想有你自己的自定義配置文件（例如在測試不同的配置文件或部署在不同的環境），你可以用傳入你自己的配置文件來覆蓋那個在classpath上的配置文件。
ConfigFactory.parseString是個選擇
val actorSystem=ActorSystem("UniversityMessageSystem", ConfigFactory.parseString("""akka.loggers = ["akka.testkit.TestEventListener"]"""))
或者
簡單的在testcase中寫
class TeacherTestLogListener extends TestKit(ActorSystem("UniversityMessageSystem", ConfigFactory.parseString("""akka.loggers = ["akka.testkit.TestEventListener"]""")))
with WordSpecLike
with MustMatchers
with BeforeAndAfterAll {
還有一個ConfigFactory.load方式
val system = ActorSystem("UniversityMessageSystem", ConfigFactory.load("uat-application.conf"))
如果你需要在runtime時訪問你自己的配置文件， 你可以這樣做：
val system=ActorSystem("UniversityMessageSystem", ConfigFactory.parseString("""akka.loggers = ["akka.testkit.TestEventListener"]"""))
println (system.settings.config.getValue("akka.loggers")) // Results in > SimpleConfigList(["akka.testkit.TestEventListener"])
B. 擴展缺省配置
不同于覆蓋，你還可以用擴展的方式來擴展缺省配置文件，只要用Config的withFallback方法。
假如你的application.conf是這樣的：
akka{
loggers = ["akka.event.slf4j.Slf4jLogger"]
loglevel = DEBUG
arun="hello"
}
并且你打算這樣覆蓋你的akka.loggers屬性：
val config=ConfigFactory.parseString("""akka.loggers = ["akka.testkit.TestEventListener"]""")
val system=ActorSystem("UniversityMessageSystem", config.withFallback(ConfigFactory.load()))
最終merge過得配置文件是這樣的的
val config=ConfigFactory.parseString("""akka.loggers = ["akka.testkit.TestEventListener"]""")
val system=ActorSystem("UniversityMessageSystem", config.withFallback(ConfigFactory.load()))
```
為什么我要說這個配置的事？因為我們的*ActorSystem*是加載并提供存取所有配置信息的點。
---
###重要筆記：
請注意下falling back的順序 - 哪一個是缺省，哪一個是擴展配置。 請記住，你需要（fall back）回滾到缺省配置。所以，
config.withFallback(ConfigFactory.load())
可以工作
但是
ConfigFactory.load().withFallback(config)
```
得不到你想要的結果。

---

文章來自微信平臺「麥芽面包」,微信號「darkjune_think」。轉載請注明。

文章出處
這是兩種不同角度考慮事情并進行推理的方式，其作用并不止于用在推理小說中。我們解決問題的過程都依賴此種科學的方式，盡管很多人可能已經忘記了。
記得大概是在初中課本中的數學歸納法第一次開始在課本中提到此種方式，具體是用歸納法來證明什么已經不記得了，所以找資料看了下，是用證明一個三角形的內角和來舉例子的。
這個例子是這樣的，通過測量幾個三角形的內角并求和，得到了一致的結果-內角和180度。這個過程就是用了歸納法，但歸納法出來的結果是一個經驗，并請注意這不一定是真理，想要證明這個要用演繹法推導。
初中課本的一個問題是教了這個東西后就要看人的悟性了，有些人就當一個知識點記在了腦力里，固化在那了，并沒有和后面學到的證明題方式聯系起來，盡管課本里需要做的題目其目的就是要訓練這種思維。
說了半天，看一下百科中的定義
歸納法定義：

所謂歸納推理，就是根據一類事物的部分對象具有某種性質，推出這類事物的所有對象都具有這種性質的推理，叫做歸納推理（簡稱歸納）。歸納是從特殊到一般的過程，它屬于合情推理。

演繹法定義：

所謂演繹推理，就是從一般性的前提出發，通過推導即“演繹”，得出具體陳述或個別結論的過程。演繹推理的邏輯形式對于理性的重要意義在于，它對人的思維保持嚴密性、一貫性有著不可替代的校正作用。

以上的思維方式一樣可以用在日常程序員找bug過程中，如發現了某個線上問題，根據這個問題上的一些表象（cpu load過高，io吞吐很大，內存占用Out of memory）來推導發生問題的原因，是操作系統的問題，還是硬件上的問題，還是自己寫的代碼太爛，是不是出了死循環。
這種思維方式在所有的科學研究中都在應用。但科學研究是個探索的過程，這個過程不可避免的遇到非常多的現有知識體系不能解決的事情，在這種過程中科學探索的一線人員（科學家）就會跟撞了墻一樣，發現自己堅信的東西走不通了。越是卓越的科研人員越是有可能走向另外的極端，如晚年的牛頓開始研究神學。
物理學上似乎更容易產生一些人類認知無法解釋的事情，比如宇宙的形成,地球是如何開始自轉的，宇宙的邊界在哪里，宇宙有沒有邊界，有了邊界那么邊界外邊是什么，量子物理與相對論在宏觀與微觀為什么是沖突的。
這些問題的答案是否能用現今的歸納法和演繹法來進行推理，從浩瀚的自然現象中歸納出經驗，再用演繹法來證明其合理性。
現代基本上還沒有思維形態上的大突破，現代人無法體會現在已經認識是常識的東西在當年提出產生的劇烈的社會動蕩，當年的地心說變成日心說的過程遠不是一個哥白尼的悲慘遭遇能涵蓋的，這個意識上的變更在當時產生了深遠的社會影響，例如文藝復興。
再如哥倫布發現了新大陸，麥哲倫真正通過事實證明了地球是圓的猜測。
我們現在認為所謂的常識的東西，隨時可能在若干年后被顛覆。
例如，多年后你發現你現在經歷的一切只是matrix給你的一個幻象而已，就算你知道了，你會選red or blue? 繼續在虛幻中醉生夢死還是到現實中接受殘酷的生存現狀。

---

文章來自微信平臺「麥芽面包」
微信公眾號「darkjune_think」
轉載請注明。長按圖片識別關注公眾號。

文章出處
你有沒有推倒重來的勇氣？
推倒重來,這里是指將自己在某個領域積累的放棄,另開爐灶重頭開始干.人在自己的舒適區太久,很容易陷在里面無法自拔,想脫離這種現狀,卻又沒有足夠的勇氣放棄.完全跨領域是比較極端的,大多數人的重起爐灶還是可以在自己本身的領域上自然的延伸,不用體驗如此劇烈地變動.
Case A
一個程序員小a,跳槽前在一家公司做的是資深工程師,對自己的這一塊能獨當一面,談了一家公司去做lead了,上來就給了一個公司初期的外包項目,配了若干個員工要運轉起來.這時的小a就要面臨一個較大的挑戰,首先他要把這個自己并不熟悉的項目撿起來,包括業務上的理解和技術上的熟悉, 同時在這個職位上不是自己管好自己的事就行了,還要保證能讓其他的同事跟上項目的規劃和要求.
這是一個開荒期,這個時期過了之后(可能是幾個月,可能是一年),小a已經熟悉了項目上的方方面面, 對于自己團隊的小伙伴的特長一清二楚, 如何能更好的幫助小伙伴成長是小a每天都要想的;業務上面對產品也已經比較熟悉,能有效的規劃產品上的功能維護;團隊外部在各方面的合作上人員都比較熟悉了,什么樣的事找誰能處理,分分鐘解決.
以上從一個單兵技術人員到能帶團隊一起戰斗的lead的變動就算是一種推倒重來,放棄自己之前擅長的領域,加強在其他領域的技能.
Case B
互聯網行業隨著國內網絡基礎設施的建設成熟及價格降低,培養了大家的上網習慣,也隨之爆發性增長.5,6年前it行業大家最想去的都是高大上的外資公司,有異國文化交流,有機會派到國外出差,甚至長期出差就能移民. 當今技術玩的最high的變成了互聯網公司, 面對著國內大量的網民, 要用技術痛苦的支撐用戶數量的爆發增長, 痛并快樂著.
原企業開發領域的it工程師要往互聯網行業走,必然要經歷的就是自己原有技能與目標崗位要求的阻抗不匹配,原有崗位不能接觸到的,或很少接觸的互聯網技術,如何自學并應用在自己的實際工作中,是件比較困難的事.參與開源軟件的開發是條路,但能堅持在上班之余,業余時間還在進行編碼工作的人,一定是真愛,目測也是不多.
這也是不完全態的推倒重來的例子.
我們每一次學校的升級也是在推倒重來,小學,初中,高中,大學,每次都會遇見不一樣的人,全新的知識,陌生的環境. 初中的尖子,進了省重點就成了普通人, 省重點的尖子, 在211又是普通人,不斷地螺旋上升,循環周轉.
舒適區呆久了,成了被時代推著走的人,后面的人生選擇都要被動,無法自由選擇.
能掙扎著跳出舒適區,在到達下個舒適區前會有一段時間不舒服,這是種態度.在時代浪潮前要有一定的提前量,領先一兩步,在一些轉折點才能做到主動選擇,追求自己的目標.
這跟現在的中國從唐到清到現代也有點像.

---

文章來自微信平臺「麥芽面包」
微信公眾號「darkjune_think」
轉載請注明。

文章出處
線上發現一個問題,應用在啟動時會卡死,log上并沒有什么異常輸出,初判應該是死鎖問題.
抓現場的thread dump文件, 確實是有兩個線程有deadlock問題.
線程一
"HSFBizProcessor-8-thread-13" daemon prio=10 tid=0x00007fc686a83000 nid=0x37128 waiting for monitor entry [0x000000004b7f3000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinitionNames(DefaultListableBeanFactory.java:192)
- waiting to lock <0x00000007707d84c8> (a java.util.concurrent.ConcurrentHashMap)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanNamesForType(DefaultListableBeanFactory.java:209)
at org.springframework.beans.factory.BeanFactoryUtils.beanNamesForTypeIncludingAncestors(BeanFactoryUtils.java:187)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:652)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:610)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:412)
at org.springframework.beans.factory.annotation.InjectionMetadata.injectFields(InjectionMetadata.java:105)
at
線程二
"main":
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:180)
- waiting to lock <0x00000007707ae6c0> (a java.util.concurrent.ConcurrentHashMap)
at org.springframework.beans.factory.support.AbstractBeanFactory.isFactoryBean(AbstractBeanFactory.java:747)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:422)
- locked <0x00000007707d84c8> (a java.util.concurrent.ConcurrentHashMap)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:728)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:380)
- locked <0x00000007707d7fc8> (a java.lang.Object)
at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
棧文件的結尾已經指出了兩個線程在競爭什么鎖,
which is held by "main"
"main":
waiting to lock monitor 0x00007fc681220a08 (object 0x00000007707ae6c0, a java.util.concurrent.ConcurrentHashMap),
which is held by "HSFBizProcessor-8-thread-13"
"HSFBizProcessor-8-thread-13":
waiting to lock monitor 0x00007fc686692438 (object 0x00000007707d84c8, a java.util.concurrent.ConcurrentHashMap),
which is held by "main"
主要是線程HSFBizProcessor的DefaultListableBeanFactory.getBeanDefinitionNames(DefaultListableBeanFactory.java:192)
需要鎖對象0x00000007707d84c8, 而這個對象已經被main的DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:422)
鎖住了.
spring的版本是2.5.
這個問題的原因是spring在初始化singleton bean的時候,需要鎖兩個地方,第一個是
DefaultSingletonBeanRegistry中的singletonObjects:
/** Cache of singleton objects: bean name --> bean instance */
private final Map singletonObjects = CollectionFactory.createConcurrentMapIfPossible(16);
...
synchronized (this.singletonObjects) {
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null) {
...
try {
singletonObject = singletonFactory.getObject();
}
singletonObjects是DefaultSingletonBeanRegistry中的并發Map.
第二步需要鎖DefaultListableBeanFactory中的beanDefinitionMap:
/** Map of bean definition objects, keyed by bean name */
private final Map beanDefinitionMap = CollectionFactory.createConcurrentMapIfPossible(16);
...
public String[] getBeanDefinitionNames() {
synchronized (this.beanDefinitionMap) {
if (this.frozenBeanDefinitionNames != null) {
return this.frozenBeanDefinitionNames;
}
...
}
}
如果在應用啟動時只有一個線程進入spring初始化bean時是沒問題的, 但這里應用代碼在spring的容器啟動的同時,有另外一個main方法同時開始運行調用spring的DefaultListableBeanFactory.preInstantiateSingletons方法,兩個線程兩把鎖,是有可能造成饑餓競爭的.
在spring容器外自行調用spring的創建bean方法要注意線程問題.
引申閱讀:
Spring Bean Creation is Not Thread Safe
A Java Thread deadlock has occured
Performance bottleneck and potential thread deadlock in DefaultSingletonBeanRegistry
Spring deadlocks between DefaultListableBeanFactory and DefaultSingletonBeanRegistry

文章出處
拍賣在中國是不太流行的一件事，為什么呢？說不太出。當初在外國火的不得了的ebay在交易時采用的就是拍賣出價的模式，但進入中國后這種方式就是玩不轉，不得以后來也變成了跟淘寶一樣的一口價方式。
話說現在每家公司都已經少不了電腦了，電腦做為it公司的資產淘汰率是很高的，不管怎么說，這畢竟是工程師們的必須的生產力工具嘛。
根據我頻率一般般的工作遷移經歷（IT行業的平均水平）來判斷，一般的公司配的電腦的更換周期是三年左右。每家公司的資產配置方式都不太一樣，有些是只配臺機，有些只配筆記本，有的是可選配哪種，還有直接給配兩個。有些鼓勵員工自購筆記本，每月給補貼，補滿三個月又能買一次；坑一點入職要自費買電腦，公司三年內將錢分期付給員工，之后電腦歸個人。有些重視成本的外包公司機器配置很低，嚴重影響開發效率，反正外包公司重視的是穩定的外包合同金額收入，至于開發效率的高低反正不是給自己公司開發產品，那不是最重要的，外包主要是靠合同時長收費的嘛。
大公司每年淘汰的電腦很多，如何報廢是個很大的問題。這次圍觀了另一種處理方式，就是將電腦低價拍賣的方式賣給員工。這樣公司又能方便的處理沒用的資產，員工又能以較低的價格拿到二手筆記本，給家里要求不高的老人用用其實還是不錯的。
拍賣在公司的內網平臺進行，有個起拍價，有意向的員工都可以在限定時間內出價，在限時結束時出價最高的人能拍到。 但由于我在的是一家互聯網公司，程序員眾多，在拍賣的過程中出現了一些喜劇性的事情。
由于我家里電腦不少，一個臺機兩個自用筆記本加公司發的筆記本，知道那天有拍賣這條事其實也沒打算參與，所以那天本應是平常的一天，但到了那天下午，竟出現了意想不到的事。
to be continue

---

文章來自微信平臺「麥芽面包」
微信公眾號「darkjune_think」
轉載請注明。

文章出處
互聯網系統7*24小時不分晝夜的為人民服務，那么這樣長時間服務的背后究竟有哪些手段保證呢？
這其中包括軟硬件，及基礎設施的保障。
IT人的努力
分布式系統
軟件架構師在設計大型互聯網系統時考慮的高可用性是從分布式系統的特點考慮的高可用。主要的思路就是在各個層面做冗余，備份。
訪問所有網頁的第一步，解析DNS, 全球十二個根服務器，從國家，骨干網，各級運營商核心機房，省級機房，局站都有DNS緩存服務器，保證解析速度。當然，大型網站專門自建的DNS服務器也都是一組集群。
提供服務的web應用只有一個服務器不安全，而部署一組同樣功能的服務器集群就降低了單個服務器產生故障的風險。
IDC
一組在同一個IDC中的應用集群在IDC級別是單點（天朝經常遇到挖光纜，遭雷劈），要將應用集群跨機房部署，此時要求應用無狀態，可以隨意部署。
IDC的建設在國內有運營商（電信、聯通、移動）和第三方基礎設施提供商（如世紀互聯），由于國內的現實狀況，運營商提供的IDC網絡質量較好，但是不能提供多線互通；而第三方質量比較參差不齊，有好有壞，但能提供BGP多路接入，一般出口帶寬較小。
最高級的T3機房的設計要求一條就是要能抗8級地震，也就是跟幾年前汶川一樣的震級。
高可用軟件
Heartbeat與keeplived，此類軟件采用IP漂移技術，主要側重在做服務器的主備切換，在一些本身沒有集群功能支持的產品上，如早期Redis上能做簡單的主備高可用，并對應用本身無感知，簡化應用開發。如果單個一組主備的redis不能滿足容量需求，需要做Redis集群，則要用一些簡單工具庫人為對redis的讀寫進行分片（如jedis），此時集群維護成本變高，最好組件本身有原生的集群功能支持。
存儲
數據庫服務器用的硬盤使用raid10保證本地硬盤上的冗余，再通過linux LVM卷管理做本地存儲冗余備份，再通過存儲廠商的商業解決方案或自研技術將單IDC的數據復制到同城異地IDC的存儲系統中，保證如果源站IDC被毀（極端的地震，戰爭），在同城另一個機房仍有可恢復的備份。
當然如果有地震，那么同城容災就不夠了，還需要異地容災，因為地震通常是區域性的，杭州地震不會對上海機房有很大影響。
光在存儲上做異地容災是不夠的，如果是冷備，平時并沒有用起來，也沒有合理的機制做演練切換，真到了一個IDC故障需要將應用讀取切到備庫上去的時候，沒人心里有底敢做這個決策，尤其是金融系統，數據庫一旦出錯會對企業造成可能致命的資損故障。
可以參考工商銀行2013年6月23日波及全國的長時間停機故障，說明我國國有銀行IT信息化技術儲備仍然薄弱，主要解決方案還是被美國廠商綁架。
國企背景的辦事思路一般找500強咨詢公司要方案并實施，這樣負責人可以不用擔職業前途的風險，出問題了全部推到合作方身上，并不考慮自己能為企業提供什么價值，典型的官場思維，當然這是題外話了。這個問題現在運營商高層應該已經認識到了，能看到目前運營商的思路有了一些變化，開始在自營業務上做技術和人才的儲備了。
設備
常用的硬件負載均衡設備如F5，在設計上都是采用雙機冗余，心跳信號可以走設備串口或TCP。
一個4U的機架式服務器，都有冗余的電源設計（2+1，2+2,3+1）等，千兆網卡多塊。冗余的電源可以被芯片控制進行負載均衡，與程序員熟知的keeplived做的HA一樣，當一個電源不行時可以進行切換。
電力
云計算背景下，單機柜服務器部署密度的增加，對于電力的要求也越來越高，在一個部署了4到6個刀片服務器的機柜最高需要30kW的電力。
電力的冗余體現在UPS和柴油發電機上。并且大型數據中心采用兩路獨立供電路徑，保證一路電力掛掉后另一路仍能為整個數據中心進行供電。
用戶享受了
可以看到一個7*24小時的系統需要在方方面面上考慮系統的可用性, 軟件架構師要考慮在架構上支持容災；運維工程師要考慮機房網絡，服務器等能滿足業務需要；而IDC的建設要考慮選址（避開地震帶），電力供應，制冷等建筑規劃，能耗上的約束；設備廠家要考慮的是自己的產品能減少硬件故障宕機時間。
所有的努力，最終改變了人們的生活：
你可以坐在家里購物；快遞提供迅速的物流；用手機打車，叫外賣；不分白天黑夜的玩網絡游戲；隨時隨地用微信搶紅包；在便利店用手機付款；與爸媽遠程聊天。
程序員主宰世界！

---

文章來自微信平臺「麥芽面包」
微信公眾號「darkjune_think」轉載請注明。
如果覺得有趣，微信掃一掃關注公眾號。

文章出處

本文翻譯自blog.trifork.com的博文
地址是http://blog.trifork.com/2013/10/24/how-to-avoid-the-split-brain-problem-in-elasticsearch/ ，可以復制后在瀏覽器觀看。

我們都遇到過這個 - 在我們開始準備一個elasticsearch集群的時候，第一個問題就是“集群需要有多少節點？”。我想大家都知道，這個問題的答案取決于很多因素，例如期望的負載，數據大小，硬件等。這篇博文不會深入解釋如何調整集群大小的細節，而是去關注另一個同樣重要的事情 - 如何避免腦裂問題。
什么是腦裂？
讓我們看一個有兩個節點的elasticsearch集群的簡單情況。集群維護一個單個索引并有一個分片和一個復制節點。節點1在啟動時被選舉為主節點并保存主分片（在下面的schema里標記為0P），而節點2保存復制分片（0R）
現在，如果在兩個節點之間的通訊中斷了，會發生什么？由于網絡問題或只是因為其中一個節點無響應（例如stop-the-world垃圾回收）,這是有可能發生的。
兩個節點都相信對方已經掛了。節點1不需要做什么，因為它本來就被選舉為主節點。但是節點2會自動選舉它自己為主節點，因為它相信集群的一部分沒有主節點了。在elasticsearch集群，是有主節點來決定將分片平均的分布到節點上的。節點2保存的是復制分片，但它相信主節點不可用了。所以它會自動提升復制節點為主節點。
現在我們的集群在一個不一致的狀態了。打在節點1上的索引請求會將索引數據分配在主節點，同時打在節點2的請求會將索引數據放在分片上。在這種情況下，分片的兩份數據分開了，如果不做一個全量的重索引很難對它們進行重排序。在更壞的情況下，一個對集群無感知的索引客戶端（例如，使用REST接口的）,這個問題非常透明難以發現，無論哪個節點被命中索引請求仍然在每次都會成功完成。問題只有在搜索數據時才會被隱約發現：取決于搜索請求命中了哪個節點，結果都會不同。
如何避免腦裂問題
elasticsearch的默認配置很好。但是elasticsearch項目組不可能知道你的特定場景里的所有細節。這就是為什么某些配置參數需要改成適合你的需求的原因。這篇博文里所有提到的參數都可以在你elasticsearch安裝地址的config目錄中的elasticsearch.yml中更改。
要預防腦裂問題，我們需要看的一個參數就是 discovery.zen.minimum_master_nodes。這個參數決定了在選主過程中需要 有多少個節點通信。缺省配置是1.一個基本的原則是這里需要設置成 N/2+1, N是急群中節點的數量。 例如在一個三節點的集群中， minimum_master_nodes應該被設為 3/2 + 1 = 2(四舍五入)。
讓我們想象下之前的情況下如果我們把 discovery.zen.minimum_master_nodes 設置成 2（2/2 + 1）。當兩個節點的通信失敗了，節點1會失去它的主狀態，同時節點2也不會被選舉為主。沒有一個節點會接受索引或搜索的請求，讓所有的客戶端馬上發現這個問題。而且沒有一個分片會處于不一致的狀態。
我們可以調的另一個參數是 discovery.zen.ping.timeout。它的默認值是3秒并且它用來決定一個節點在假設集群中的另一個節點響應失敗的情況時等待多久。在一個慢速網絡中將這個值調的大一點是個不錯的主意。這個參數不止適用于高網絡延遲，還能在一個節點超載響應很慢時起作用。
兩節點集群？
如果你覺得（或直覺上）在一個兩節點的集群中把minimum_master_nodes參數設成2是錯的，那就對了。在這種情況下如果一個節點掛了，那整個集群就都掛了。盡管這杜絕了腦裂的可能性，但這使elasticsearch另一個好特性 - 用復制分片來構建高可用性 失效了。
如果你剛開始使用elasticsearch，建議配置一個3節點集群。這樣你可以設置minimum_master_nodes為2，減少了腦裂的可能性，但仍然保持了高可用的優點：你可以承受一個節點失效但集群還是正常運行的。
但如果已經運行了一個兩節點elasticsearch集群怎么辦？可以選擇為了保持高可用而忍受腦裂的可能性，或者選擇為了防止腦裂而選擇高可用性。為了避免這種妥協，最好的選擇是給集群添加一個節點。這聽起來很極端，但并不是。對于每一個elasticsearch節點你可以設置 node.data 參數來選擇這個節點是否需要保存數據。缺省值是“true”，意思是默認每個elasticsearch節點同時也會作為一個數據節點。
在一個兩節點集群，你可以添加一個新節點并把 node.data 參數設置為“false”。這樣這個節點不會保存任何分片，但它仍然可以被選為主（默認行為）。因為這個節點是一個無數據節點，所以它可以放在一臺便宜服務器上。現在你就有了一個三節點的集群，可以安全的把minimum_master_nodes設置為2，避免腦裂而且仍然可以丟失一個節點并且不會丟失數據。
結論
腦裂問題很難被徹底解決。在elasticsearch的問題列表里仍然有關于這個的問題, 描述了在一個極端情況下正確設置了minimum_master_nodes的參數時仍然產生了腦裂問題。 elasticsearch項目組正在致力于開發一個選主算法的更好的實現，但如果你已經在運行elasticsearch集群了那么你需要知道這個潛在的問題。
如何盡快發現這個很重要。一個比較簡單的檢測問題的方式是，做一個對/_nodes下每個節點終端響應的定期檢查。這個終端返回一個所有集群節點狀態的短報告。如果有兩個節點報告了不同的集群列表，那么這是一個產生腦裂狀況的明顯標志。

---

文章來自微信平臺「麥芽面包」
微信公眾號「darkjune_think」
轉載請注明。
如果覺得文章有趣，微信掃二維碼關注我