golang在京東列表頁實踐總結
目前線上狀態
基於以上原因，需要做出改變，所以就需要對老進行重構，如下
重構版本
為何選擇golang
基於以上兩點，所以選擇了golang語言作為服務端計算使用的語言。
重構後的架構圖
解釋下架構圖各個模組功能
nginx+lua: 用來渲染頁面，拿到go計算服務的json資料渲染到頁面端，最終呈現給終端使用者；
config center 是用來協調worker、lua服務以及go計算服務的控制中心；
計算最優資料，計算完成後會通知 config center，同時資料會進入db，進行持久化；
深 黃色部分是go計算服務，只要分2個集群，乙個線上集群、乙個線下集群，非同步計算服務根據配置中心選擇乙個線下集群進行資料計算，計算完成後會通知 config center，然後相應的線下集群會進行資料預載入到分片的redis以及go計算服務的各個節點中，然後線下集群準備就緒，可以隨時切到線上提供服務；
mq worker是乙個處理訊息的服務，主要包括sku上架、下架、庫存變動、以及**變動等訊息；
msg receiver 接受到mq worker的訊息後進行訊息處理，然後傳送的go計算服務的各個節點中；
線上部署的多個機房，避免單機房故障；
資料處理流程如下圖所示：
流程，整個流程中最核心的部分是架構圖中的config center，資料流程中的每一步操作都依賴於配置中心。所以整個架構中配置中心非常重要。
記憶體計算模型圖
簡單介紹下計算過程：
解析頁面傳過來的引數，整理成相應的結構體；
格式化的結構體，比如品牌、**、sku屬性、庫存、產品標籤、排序型別等；
通過格式化的結構體進行記憶體中計算，包括過濾、排序等計算操作；
；然後通過id列表獲取到產品的詳細資訊，並對產品屬性過過濾；
最終把結構化的json資料返回給lua，進行頁面渲染；
記憶體計算資料結構
如下圖所示：
以 上結構是go的乙個結構體，包括了頁面上所有要進行計算的屬性，後續所有的記憶體中計算過濾、排序都是基於此結構體進行，每個商品對應乙個相應的結構體，每 個分類大約有幾萬個商品，記憶體中也有對應的結構體。這些結構體是在資料異構完成後，資料預先載入記憶體，避免在提供服務的時候再去初始化。
開發過程中遇到的問題
遇到2個比較嚴重的問題：
針對第乙個序列化、反序列化問題，我們嘗試過golang內建的encoding/json、encoding/gob兩種方式，但是效果都特別不理想，耗費cpu過多，qps 一直上不去。
後來請教beego作者的謝大同學，給推薦了ffjson，也親自寫了一些測試ffjson的**，最終ffson以3倍優勢完勝golang內建json序列化，所以最後採用了ffjson。
第二個問題，golang gc問題，相信不少同學在開發的過程中也遇到過這個問題，其實我們認真分析，發現gc時候很大部分時間是浪費的marking階段，所以我們可以從以下幾個點優化我們的**：
減少記憶體中物件數量
盡量重複記憶體申請，採用物件池，避免重複申請、釋放記憶體，可以非常有效的減少gc；
開啟godebug=gctrace=1，可以非常清晰的看到記憶體中物件數量、記憶體使用情況。以及各個階段的時間開銷；
工具pprof包，可以方便得監控到記憶體、cpu的是使用情況。
go 技術棧選擇
json序列化，裡邊有詳細的使用說明文件；
redis： 在這之上我們內部又對主從操作封裝了一層；
今日話題 聯想在京東全部下架，渠道之爭？
昨天在京東 上已經基本找不到聯想旗下的 lenovo moto zuk 以及子品牌 樂檬 的手機產品。行業內傳聞是聯想集團總裁兼ceo楊元慶參與了昨日阿里蘇寧戰略合作，引發了京東的 報復 目前，在阿里或蘇寧兩個平台上的聯想手機仍正常在售。但在京東 上尋找聯想旗下的lenovo，moto，zuk等品牌...
在京東成為優秀的技術leader，需要做到這三點
我認為需要關注如下三點 穩定，高效，創新。我認為作為一名技術 leader，作為系統架構的負責人，系統穩定是首位的。更毫不誇張的說，系統穩定是研發團隊的脊梁骨。其次，研發效率是研發的天職，不高效的團隊是沒有競爭力的。而技術創新是進步的主要生產力。實現系統穩定，重要做到兩點 所以，總結出了問題，怎麼辦...
scrapy 爬取京東商品列表
import scrapy class jdspider scrapy.spider scrapy crawl name便是由這個name決定的 name jd def start requests self url yield scrapy.request url url,callback sel...