魅族經過2014-2023年的轉型以及銷量大爆發後，隨之而來的網際網路服務業務越來越多，使用者基數越來越大，之前單機房的擴充套件架構已經滿足不了魅 族的發展，此外加上國內複雜網路環境下，單機房無法滿足我們的可靠性需求。近年經常出現的光纜被挖、機房掉電。如支付寶光纖被挖斷，導致業務中斷；去年微 信也出現大面積故障，同樣是光纖被挖斷。除了單機房故障風險外，使用者就近接入的需求也很強烈。
機房之間的網路延遲和頻寬限制, 租用運營商的專線非常昂貴，可靠性也得不到保障；
業務依賴關係複雜；
機房之間流量的精確排程；
業務改動不能太大。
我們借鑑以上幾種方案，把業務進行一些梳理，對映到下面兩種業務：
讀多寫少
這類業務主要是讀取，極少寫入，所以我們甚至把這類業務歸納為唯讀業務。
應用商店單機房架構
如下圖：
接入端分三種業務，api、開發者社群、運營後台。
後台提供給公司內部運營部門使用，榜單維護、應用上下架等功能，也有較多的「寫」。
經過對業務可用性做分級，應用商店(api介面)的可用性要求最高，運營後台和開發者社群的可用性需求稍低。
基於以上分析，我們只需要對應用商店(api介面)提供多機房方案。
應用商店多機房架構
如下圖：
核心機房的部署基本不需要改動，我們華東機房的資料通過mysql的同步功能複製，榜單類資料的讀取與核心機房一致，從redis快取讀取。redis快取的資料實用定時任務從db裡獲取定時刷到redis裡。
為了保證資料一致性，"寫"依然是單點寫，是跨機房直接寫入核心機房。分兩種，一種是通過訊息佇列，寫入遠端機房，即使機房間網路出現問題，我們 的"寫"可以堆積在mq裡，基本不影響使用者體驗，堆積的資料待網路通順後再拉去。另一種"寫"要求馬上知道是否"寫"成功，所以是跨機房直接寫入資料庫， 這部分如果網路出問題，將導致失敗，我們可以做降級處理。
另外機房間流量排程我們實用gslb來排程，後面有詳細闡述。
讀寫均衡業務
我們這裡的讀寫均衡業務有乙個重要特性，就是所有資料可以按照使用者維度來切分。相互關聯度不大。例如我們的同步業務，同步業務把手機端的所有資料 （聯絡人、簡訊、設定、wifi、輸入法偏好 ...）同步到雲端，遇到手機丟失、刷機需要清資料時，可以隨時把資料拉下來，做到資料永不丟失。
下面是同步業務單機房架構：
這裡做跨機房方案比較方便，直接按照使用者做全域性路由，路由到不同機房即可。
跨機房架構圖如下：
我們把業務資料和服務打包到單個unit，乙個unit服務一定數量的使用者。每個unit包含了完整的資料和服務，可以單獨部署。每個機房有多個unit,每個使用者的資料在本地有乙份備份、在遠端同樣也有乙份備份。當機房故障時，可以把備份資料拉起來服務使用者。
使用者通過api訪問我們的服務時，使用gslb來做排程，使用者訪問業務服務時，先從gslb獲取使用者資料所在位置（使用者資料同時僅在某乙個機房提供服務），然後把客戶端請求排程到合適的機房。
web請求是乙個挑戰，因為web服務無法使用gslb，所以不能精準的排程使用者請求。這塊的方案在後續的流量排程裡講到。
說到多機房，就牽涉到流量排程。流量排程最簡單的就是使用智慧型dns服務。如下圖：
只能dns根據localdns來的請求裡的ip來判定您是哪個那個isp，哪個區域的使用者，從而排程到對應isp,對應區域的機房，核心在智慧型dns的ip庫。有幾個缺點：
dns劫持, 在我國，dns劫持時有發生，尤其是二三線城市的運營商，明目張膽。這在智慧型dns基本無法解決
本地dns如果設定成使用者自己指定的dns伺服器如8.8.8.8，智慧型dns伺服器獲取到的localdns是美國位址，也無法對應isp,智慧型dns服務只能按設計者喜好提供解析了，這時可能給使用者解析到錯誤的isp和錯誤的機房。
無法根據使用者資訊來排程，有些資料只在特定機房有，由於dns協議無法攜帶使用者標示，所以也很難做到精準解析。
無法感知伺服器宕機。
由此就針對特定業務，我們接入了gslb服務:
這個服務避開dns請求，發起請求前，訪問我們自己的gslb服務(或者 httpdns),業務可以帶上使用者標識，來定位自己的資料在哪個機房，使用ip來訪問業務服務。
帶來幾個明顯好處：
* 可以根據ip或者uid等等資訊精確排程。目前我們所有客戶端的訪問，都接入gslb，例如上面提到的應用中心、使用者同步的api訪問等。* 避免dns劫持。
* 使用者手工設定dns也不會排程錯誤。
但是也存在問題，這種方案僅適應於有客戶端的http、https請求，不適合瀏覽器訪問，瀏覽器不清楚你的gslb是什麼東西。使用者同步的api 訪問可以用gslb來做，但是web訪問的時候，是不能用gslb來做流量排程的，因為瀏覽器不認gslb, 如果使用智慧型dns也無法根據使用者id精準排程流量。
基於以上考慮，我們提出了第三種方案，gslb+智慧型dns：
使用者請求服務前，找到dns解析到的乙個伺服器，去獲取資料，後端服務會先找gslb服務查詢使用者資料所在機房，如果使用者資料在本機房，則直接返回資料，否則，重定向使用者請求到合適的機房重新發起請求。
這種方案可能導致使用者瀏覽器裡網域名稱變換，影響使用者體驗，另外依然無法避免網域名稱劫持。
我有幾個問題，
1是對於第二幅圖 應用商店多機房架構， 如果使用者通過華東機房進行寫操作，但寫操作需要通過mq同步到另外的機房，這樣其後序的讀操作是否會明顯感覺到延遲？
2是mysql資料庫與redis的同步 是通過什麼技術完成的？ 謝謝
1.對於延遲要求高的資料，我們的寫是直接跨機房寫。走mq寫資料時，這類資料對延遲並不敏感。
2.過乙個定時任務，定時從mysql讀取資料，組織成展示需要的資料形式put到redis集群裡
博主，如何根據uid定位機房? userid跟機房的對應關係是怎麼維護的？謝謝
使用者資料初始生成時，這個使用者的資料就與某乙個機房關聯上了，使用者訪問資料時，拿自己的uid去我們的gslb服務獲取資料所在機房。
應用多機房部署
通常乙個產品，內部是需要很多子系統一起協助的，像有些電商系統，可能需要幾百個系統一起協助。假設下面這樣一種場景，假設應用a部署在機房room1，在room1的其他應用可以呼叫應用a的介面，然後還有很多的子系統是部署在room2這個機房的，room2中的應用也需要呼叫到應用a，那麼這樣room2中的應...
魅族手機中遮蔽ListView下拉懸停方法
魅族手機中有個feature，所有的listview中又下拉懸停的樣式。如果只是單獨的listview，還是可以接受的，如果有下拉重新整理或者排序功能，就顯得很蛋疼。可以利用下面方法去掉，xml中新增如下屬性。android overscrollmode never 或者 修改 listview.s...
魅族手機中遮蔽ListView下拉懸停方法
魅族手機中有個feature，所有的listview中又下拉懸停的樣式。如果只是單獨的listview，還是可以接受的，如果有下拉重新整理或者排序功能，就顯得很蛋疼。可以利用下面方法去掉，xml中新增如下屬性。android overscrollmode never 或者 修改 listview.s...