重量级应用转轻量级：IP查对应城市，IP所在城市设计思路

原创思路 免费分享

对于专业做IP查询的公司，这种方案是小儿科，但对于非专业公司或个人，这方案很值得借鉴。

适应环境：
1、网站
2、APP
3、本地

主要设计思路：梯形数据模块
查询方式1：服务器查询
查询方式2：本地查询
查询方式3：WEB客户端JS查询

一个朋友的网站需要知道用户所在城市，用户IP很容易得到，但用户所在城市对应的数据库太大(1G)，共1000万+条数据。
这位朋友第一反应就是在服务器上搭建k/v内存数据库(redis或者Mencached)，在程序跑了1周左右，高并发服务器受不了，成本也高，求我给个低成本高效率的方案。

想让马儿跑又不给马儿吃草，是我设计程序的主要核心思想。
在抽了根寂寞后，我想到一个绝佳的方案，既可以快速查询用户的IP对应城市，而且只用很小小小小小小小的服务器资源

骚点子总是在寂寞之后

一个搞美术的架构师给出的IP查对应城市低耗能方案
想让马儿跑又不给马儿吃草，是我设计程序的主要核心思想。
1、用户IP只需要一行代码唾手可得
2、要查出IP所在城市有个数据库也能得到，可服务器受不了，钱包也受不了

那么问题所在就是数据库太大(1G 1000万+数据)，查询的时候消耗服务器资源
1、优化数据库
2、增加服务器配置

NO NO NO NO NO NO NO NO NO NO !
都不是，我不想给马儿吃草

我们想知道什么？？？？
答：用户所在城市
那么问题来了 “用户所在城市” 和 “用户是不是在这个城市”，对于中文系的同学来说，描述手法不同但意思是一样的。对于程序的世界来说，完全是2条路。
例1：我们想知道用户所在城市，我们需要问数据库，这个用户是哪个城市的？数据库(查询一轮)答 “在某某城市”
例2：我们想知道用户是不是在这个城市，我们问数据库，这个用户在某某城市没有？数据库(查询某某城市一轮)答 “yes” or “no”
这2个例子的结果一样的，但对于数据库来说工作范围不一样，执行时间也不一样

那么既然有区别，也明确知道了方向，我们就直接下一步深挖逻辑
逻辑1：用户是否在XX城市，和用户到底在哪个城市， 答案都一样，我们就不需要关注消耗性能更多的"用户到底在哪个城市"这个问题，我们只需要把重点放在“用户是否在XX城市”
逻辑2：用户是否在XX城市，我们数据库设计是不是可以优化？我们可以把某个城市的所有IP段都分为一个表进行查询，这样服务器性能消耗就会降低几百倍，但问题又来了，我们应该问数据库什么问题？？？因为城市有几百个，不可能全部都问
逻辑3：分析用户IP特征11.22.33.44，我们可以逆向思维，把原来按城市分表变成按IP头分表，IP有0-255段，一共256个表
逻辑4：用户IP头为11，我们查询11这个表，成功给服务器减轻99.609375%的压力
逻辑5：但是这样还是消耗了太多服务器资源，因为要用数据库或者K/V数据库，还要用动态程序查询，虽然减轻了99.6%的压力，但还是不满意，因为我压根就不想给马儿吃草
逻辑7：既然可以按IP头分表，我们是否可以按IP头和IP头2再细分？例IP为11.22.33.44，我们单独把11.22分为一个小段，里面放11.22.*.*的IP对应城市
那么我们会得到很多这样的分段
11_22.js 或 11_22.json
11.22.31.** A市
11.22.32.** B市
11.22.33.** C市
11.22.34.** D市
11.22.35.** E市
大概(256x256=65536)个分段，每个分段大概200-300条IP数据，平均大小17K左右
逻辑8：既然只有17K大，我们可以做成JS/json，一共60000个(静态)JS/json在服务器上，根据用户IP头1头2，自动下载对应文件，然后本地查询
逻辑9：这样的设计就相当于把1G的数据库打散也6万个小数据库，传输给用户，让用户浏览器查询。

这样设计服务器只是多了60000个静态文件，不需要数据库，不需要动态语言来执行，只需要多传输一个17K左右的文件给用户，对于服务器来说完全没压力，对于宽带来说也没压力
给马儿看一眼草，还让马儿跑得飞快，完美解决！

我知道各位程序员是怎么想的，这是一个笨办法、土办法，想我堂堂程序员，冠面格子衫，写这样的程序很丢人，我只能呵呵。
很久以前我也是个程序员，C VB ASP PHP、PY等等，什么语言都玩过，程序的世界很奇妙，无论程序再花哨也配不上格子衫的骚气。
我告诉你，程序是达到目的的工具，不需要粉饰。只有跑起来顺畅和低能耗的程序才有灵魂，这种灵魂内敛的风骚才有韵味。花里胡哨的程序那真不是水平，是太年轻。