有大佬雄心勃勃，準備打造乙個地理資訊平台，作為基礎服務，支撐各種應用。其中一項指標，是要能經得起一定量的併發訪問。
這是自然，基礎服務嘛。高併發的套路，如前所學，無非就是非同步機制、負載均衡、快取、分布式資料庫之類。
地圖服務沒有什麼來自於使用者的資料寫入，主要是讀取，非同步機制估計用不上；但訊息佇列還是要的，可以起到削峰的作用。
地圖服務是無狀態的，伸縮性相對比較好處理，但也有可能在多集群甚至單集群中，不同機器提供的服務，儲存的資料不一樣，所以負載均衡演算法要依據情況而定。
快取對於地圖來說，就是切片。切片檔案應該儲存在固態硬碟，或者載入到記憶體中才夠快。
地圖中的動態圖層，資料源自資料庫，如果需要比較高的效能，最好採用分布式資料庫。nosql天然支援分布式，也適合空間資料的儲存，但nosql不支援sql，通常按鍵值查詢，組合查詢支援很弱；另外對空間索引支援也不好；而傳統關係型資料庫對空間資料庫支援良好，結合緊密，但無法應對海量儲存和高併發訪問，因此可以將關係型資料庫與nosql結合作為空間資料庫的儲存方案。其中關係型資料庫可以儲存簡略的空間資訊，而nosql可以儲存詳盡和歸檔資料，作為後備和補充。
總體結構（圖來自網際網路，有相似性，借用一下）
arcgis方案。地圖服務不一定就要用arcgis。
有一幅圖我看了覺得很牛，雖然跟本文論述沒啥關係，也碼下來，作為學習之用。
上圖中說，為了高併發寫入，hbase採用了lsm儲存模型。lsm是一種儲存結構，關係型資料庫一般是b+樹，雜湊樹啥的。b+樹等儲存結構寫入的時候，需要耗費一些資源來構造這個樹，優點是之後查詢速度***，缺點就是寫入費時。而lsm這種結構，查詢沒有b+樹快，但寫入簡單，速度就比較快。當然它查詢速度也不一定很慢，還是會有一些處理。
arcgis雲
具有 gis 伺服器集群的多機部署
基於nosql資料庫的空間大資料分布式儲存策略
獲取ip地理資訊
第一種是利用純真ip資料庫，這個可以在網上找到很多，缺點是更新有點慢。第二種是利用門戶 的介面 網易有道的ip位址查詢介面 檢視源 列印幫 function getipplace ip getipplace print r ip 呼叫查詢介面需要抓取網頁，有三種方法，第一種是curl，第二種是 fi...
ios 地理資訊反編碼
clgeocoder geocoder clgeocoder alloc init geocoder reversegeocodelocation manager.location completionhandler nsarray placemarks,nserror error if place...
Google 地理資訊反解析
android 為位址反解析提供了標準的api 方案，但該方案並不是android sdk的一部分。手機使用者要想 正常使用該功能，手機上必須安裝 google map。但國內沒有廠家缺省內置google map,手機使用者也不可能 自動安裝。反解析的方案國內應該可以通過baidu地圖api介面，國...