之前開發了將近兩年的棋牌遊戲，都是在創業公司上班，不論前端後端都自己一個人做，怎能一個累字了的。最重要的是錢不到位^_^。
先來說說我自己理解的分佈式，我們的遊戲是玩虛擬幣的，分了好幾種類型的玩法合在了同一個遊戲。每個玩法都是在單獨的一個進程中，進程之間可以通過網管或者redis的訂閱、發佈模式相互通訊，網關維護所有的客戶端鏈接。多個進程玩法結合起來一起運行就構成了所謂的分佈式架構。開發了一段時間也對這種模式有一定的發言權。首先說說優點。
1）每個進程模塊之負責一個玩法的實現，所以開發起來耦合低，易於維護。
2）由於模塊之間不相互依賴，所以當一個玩法出現問題的時候在沒有熱更新的情況下只需要關閉一個進程而不影響其他玩法的進程。
3）如果出現某個玩法人多的情況下可以將該玩法的進程單獨跑在一個服務器上，容易橫向擴展。
這是我目前對分佈式運用優點的理解，現在說說缺點。
1）小型遊戲，特別是這種棋牌遊戲有寫需求很不適合使用分佈式，不是說用不了，而是開發難度大，成本高，不值得使用。
就說說我在開發中遇到的問題吧
因爲是分佈式架構，每個玩法一個進程，但是就有那麼幾個令人頭疼的需求，發紅包和類似彩票的需求
先說說紅包功能，就是你發了一個紅包，其他所有玩家不論在那個進程都能參與過來一起搶，這就有了需要進程之間同步金幣的的問題，還有一個類似的問題就是彩票，它是掛在另外一些場景中作爲二次玩法的。如果說紅包同步量小那沒什麼，但是這個的同步兩就有點大，比如我這某個場玩，然後又在彩票場下注，那彩票每一個玩家每下一次注都需要將金幣同步到當前所在的場，這同步量就有點大了，而且分佈式同步在開發中工作量大不說而且開發難度也隨着增加。我在這給出的方案是用redis上的玩家數據爲準，每次修改金幣都先修改redis上的數據再同步到當前進程內存當中，當在彩票場下完注就用redis自帶的訂閱、發佈方式通知其他進程將redis上的數據更新到本地。但redis並不應該存儲這類經常變動的數據，而且這下注操作沒一次都需要先更新redis再同步，再通知這樣一來說實話最後發現性能還不如不做分佈式的性能高，以爲對redis操作實在是太頻繁了，當然，這只是我這小菜雞的方案，如果有大神有更好的方案還是非常願意試試的。
好了，就這麼一個缺點就使我放棄了在那個遊戲上繼續使用分佈式的原因，當然如果遊戲沒有類似紅包和彩票這樣的需求，用分佈式還是很好的。所以最後想說的是如果遊戲一開始就知道並不大或者是有類似我上面的紅包、彩票功能，設計前期先別考慮什麼分佈式。大不了人多了之後分區分服就可以。謝謝板磚。