工作六七年以来，接手过无数个烂摊子，屎山雕花、开关编程已经成为常态。 下面细数一下 降低代码可读性，增加维护难度的 13 个编码“技巧”。

假设一个叫”二狗“ 的程序员，喜欢做以下事情。

1. 二狗积极拆分微服务，一个表对应一个微服务

二狗十分认可微服务的设计思想。认为微服务可以独立开发和发布，每次改动不会影响其他系统。大大提高了开发人员的效率和线上稳定性。还可以在新服务里使用新的技术，例如JDK 21

于是狗哥把微服务的思想发挥到极致，每一张表都是一个服务。系统的应用架构图十分壮观。狗哥自豪的跟新同学讲解自己设计的系统。新同学看着十几个服务陷入了思考，不停地问着每个服务的作用，干了什么。狗哥很满足。

新同学第一次开发需求，表现很差。虽然他要改10个服务，但是每个服务只改动了一点点。并且由于服务之间都是Rpc调用，需要定义大量的接口，他需要发布好多的 jar，定义版本号，解决测试环境版本冲突，测试和上线阶段可把他忙坏了。

光是梳理上线顺序，新同学就请教了狗哥 三次。 最后还是狗哥帮他上线了3 个服务，新同学才赶在 凌晨 3 点前把所有的服务发完。看着新同学买了奶茶的份上，狗哥这次才没有和领导吐槽，“这个同学不行啊，上个线都这么费劲”

微服务过多，也困扰着狗哥。虽然线上流量不高，但是由于 “微服务太多，系统架构复杂"，接口性能不行。

于是狗哥开始进行重构，他重新加了一个开关，新逻辑可以减少Rpc，调用提高性能。狗哥在代码中加了注释 "新逻辑"。

狗哥把代码上线了，但是在线上环境不敢放开，只在测试环境打开了开关。

2. 二狗积极重构代码，但是线上不放量

狗哥喜欢对代码进行重构，狗哥和领导吹牛，说“ 重构后的代码性能更强，更稳定”。 狗哥还添加了注释 ”这是新逻辑“。

但是狗哥在线上比较谨慎，并没有进行放量。只是在测试环境，放开了全量。

新接手的同学不知道线上还没放量，看到“这是新逻辑” ，他就在狗哥的“新逻辑”上改代码。测试环境验证一切正常，到了线上阶段却怎么也跑不通。

此时新同学才发现 ”新逻辑“ 的开关没有打开，你猜，他敢打开这个开关吗？ 于是他只能删代码，在旧逻辑上重新开发。 等到改完代码，再上线时，已经天亮了。

由于这次上线问题，大家一起熬夜加班，需求上线被推迟。新同学被产品和测试一顿骑脸输出。新同学委屈的想要离职。

3. 二狗喜欢挑战自我，方法长度一定要超过1000行

二狗写代码天马行空。二狗认为提炼新方法会打断自己的编码思路，代码越长，逻辑越连贯，可读性越高。二狗还认为 优秀的程序员写的方法都是 非常长的。这能体现个人的能力。

二狗不光自己写超长的方法，在改别人的代码时，也从不提炼新的方法。二狗总是在原来的方法中添加更长的一段代码。

新同学接手代码时速度很慢，即使加班到凌晨，也不理解狗哥代码设计的艺术。狗哥还向领导抱怨，”你最近招的人不行啊，一个小需求开发这么久，上线还出了bug。“

4. 二狗喜欢挑战自我，一个方法 if/try/else 要嵌套10层以上

二狗写代码十分认真，想到哪里就写哪里。 if/else/try catch 层层嵌套。 狗哥的思路很快，并且思考全面，
嵌套十几层的代码一点bug都没有，测试同学都夸赞狗哥 ”代码质量真高啊“，一个bug都没有。

新同学接手新代码时，看到嵌套十几层的代码，大脑瞬间就要爆炸。想要骂人，但是看到代码作者是狗哥……

无奈之下，自己实在看不懂这段代码，于是点了一杯奶茶，走到了狗哥工位旁，”狗哥，多喝点水，给你点了一杯奶茶。…………这段代码能给我讲讲吗？“

狗哥过几天和领导闲聊天，“新来的同学人不错，还给我点奶茶喝”

5. 二狗认为变量命名是艺术，要随机命名，不要和业务逻辑有关系

二狗觉得写代码是艺术，就好像画画一样。”你见过几个人能看懂 梵高的画？” 狗哥曾经和旁边人吹牛。

二狗写代码思路十分奇特，有时候来不及想变量如何命名，有时候是懒得想变量命名。狗哥经常随便就命名了，例如 str1，str2，list1，list2等等。不得不说，狗哥的思维还是敏捷的，这么多变量命名都能记住，还不出bug。

但是狗哥记性不大行，过一两个月就不太记得这些变量的意义了。

6. 二狗积极写注释，但是写了错误的注释

一个成熟稳重的程序员改别人代码时会十分慎重，如果有代码注释，他们一定会十分认真阅读并尝试理解它。

二狗喜欢把注释引入错误的方向，例如 “是” 改成 “不是”，“更好”改成”更差“，把两处不相干的注释交换一下位置 等。

新接手的同学点了一杯奶茶，虚心求助二狗，“狗哥，你写的这段注释有什么深意啊，我看了三天，也不理解啊”。

到时候狗哥就可以给新同学一边装B，一边讲代码了。当然还要看心情，要是不口渴，可以讲讲。

7. 二狗改代码很认真，但是注释从来不改

二狗改代码真的非常认真，但是他不喜欢改注释。最终代码大改特改，注释纹丝不动。最终代码和注释不相干，部分正确，部分错误。

新接手的同学研究了两天也没搞明白。于是求助了狗哥

到时候狗哥就可以大展神威了 。”那段注释是错的，你别管，就当没有！“

狗哥顺便还说了一句，”优秀的代码不需要写注释，也不知道是哪个XX 写的注释“，成功收割新同学的＂钦佩＂之情。

8. 二狗喜欢复制代码

狗哥写代码十分着急，根本来不及重构。他总是想到一段代码，就复制过来。神奇的是，狗哥经常这么写，但是也没出什么问题。

但新同学就惨了，在改完狗哥的代码后，总被测试同学背地里吐槽，“一点小需求咋这么多bug，跟狗哥比差远了”。原来新同学改了一处，忘了改另外几处，代码被复制了好多遍，他实在无法全面梳理。

于是每次代码写完，新同学都要不停的研究代码，总是害怕自己少改了哪些地方，下班时间越来越晚。并且新同学也不敢把雷同的代码重构到一起。（“你们猜猜他为什么不敢？）

慢慢的，组里的人都被迫向狗哥学习，狗哥成功输出了自己的编码习惯。

9. 二狗积极写技术方案，但是最终代码实现不按照技术方案来

二狗非常喜欢写技术方案，大部分时间都花在技术方案上，总是把技术方案打磨的 滑不留手。 但是在写代码时，狗哥总觉得按照方案设计写代码，时间上根本来不及啊，还是简单来吧，凑活实现吧。

例如狗哥曾经设计了一套复杂的Redis秒杀库存系统，但是实现时选择了最Low的 数据库同步扣减方案。

狗哥写的流程图和实际代码也没什么关系。 但是流程图旁边加满了注释和说明，让人觉得 ”这个技术方案很权威“。

新同学熟悉项目时，从公司文档中搜到了很多技术方案，本以为可以很快熟悉系统，但是发现技术方案和代码不太一样。越看越迷惑。

于是点了奶茶再次走向了狗哥，狗哥告诉他，“那个技术方案太复杂，排期紧张，开发来不及。你就当没那个技术方案。”

10. 二狗十分自信，从不打日志。

二狗对自己的代码十分自信，认为不会出现任何问题，所以他从来不打日志。每次开发代码时，狗哥的思维天马行空，但是从来不想加个日志会有助于排查问题。

直到有一天，线上真的出问题了，除了异常堆栈，找不到其他有效的日志。大家面面相觑，不知道怎么办。狗哥挺身而出，重新加了日志，上线。 故障持续了不知道有多久……，看着狗哥忙碌，领导不停地询问还需要多久才能上线。

复盘会上，有人对狗哥不写日志的行为进行批判，狗哥却在 狡辩 “加了日志，就能避免这次故障吗？ 出问题还不是因为你们系统出了bug，跟我不打日志有啥关系。” 双方陷入了无限的扯皮之中……

11. 二狗积极学习，引用一个高大上的框架 解决一个小问题

二狗非常喜欢学习，学习了很多高大上的框架。最近二狗学习了规则引擎，觉得这是个好东西，恰好最近在进行重构。于是二狗把 drools、avatior、SPEL等规则引擎、表达式求值 等框架引入系统。只是为了解决策略模式的问题。即何种条件下使用哪种策略。 狗哥在系统架构图里，着重讲了规则引擎部分，十分自豪。

新同学熟悉系统后，光是规则引擎部分就看了足足一周。但是还是不知道怎么修改代码。于是向狗哥请教。狗哥告诉他说，" 你在这个地方 加一行代码 rule.type == 12 ，走这个 CommonStrategy 策略类就可以了。“

新同学恍然大悟，原来这就是规则引擎啊。但是为什么不用策略模式呢？好像策略模式不费事啊！ 狗哥技术就是强啊，杀鸡用核弹。

12. 二狗积极造轮子，能造轮子的程序员才是牛掰的程序员

二狗非常喜欢造轮子，他对开源软件的大神们心向往之，觉得自己应该向他们学习。狗哥认为 造轮子才能更快地成长。

于是在狗哥的积极学习下，组里的 分布式锁 没有使用 redission，而是自己用setnx搞的。虽然后面出了问题，但是狗哥的技术得到了锻炼。# 不用Redssion硬造轮子，结果翻车了…

总结

降低代码可读性的方式方法 包括但不限于以上12种；

像二狗这样的程序员包括但不限于二狗。

大家不要向二狗学习，因为他是真的。

基础

限流是通过限制住流量大小来保护系统，它尤其能够解决异常突发流量打崩系统的问题。

算法

限流算法也可以像负载均衡算法那样，划分成静态算法和动态算法两类。

• 静态算法包含令牌桶、漏桶、固定窗口和滑动窗口。这些算法就是要求研发人员提前设置好阈值。在算法运行期间它是不会管服务器的真实负载的。


• 动态算法也叫做自适应限流算法，典型的是 BBR 算法。这一类算法利用一系列指标来判定是否应该减少流量或者放大流量。动态算法和 TCP 的拥塞控制是非常接近的，只不过 TCP 控制的是报文流量，而微服务控制的是请求流量。

令牌桶

系统会以一个恒定的速率产生令牌，这些令牌会放到一个桶里面，每个请求只有拿到了令牌才会被执行。每当一个请求过来的时候，就需要尝试从桶里面拿一个令牌。如果拿到了令牌，那么请求就会被处理；如果没有拿到，那么这个请求就被限流了。

漏桶

漏桶是指当请求以不均匀的速度到达服务器之后，限流器会以固定的速率转交给业务逻辑。

漏桶是绝对均匀的，而令牌桶不是绝对均匀的。

固定窗口与滑动窗口

固定窗口是指在一个固定时间段，只允许执行固定数量的请求。比如说在一秒钟之内只能执行 100 个请求。

滑动窗口类似于固定窗口，也是指在一个固定时间段内，只允许执行固定数量的请求。区别就在于，滑动窗口是平滑地挪动窗口，而不像固定窗口那样突然地挪动窗口。

限流对象

可以是集群限流或者单机限流，也可以是针对具体业务来做限流。

针对业务对象限流，这一类限流对象就非常多样。

• VIP 用户不限流而普通用户限流。


• 针对 IP 限流。用户登录或者参与秒杀都可以使用这种限流，比方说设置一秒钟最多只能有 50 个请求，即便考虑到公共 IP 的问题，正常的用户手速也是没那么快的。


• 针对业务 ID 限流，例如针对用户 ID 进行限流。

限流后的做法

• 同步阻塞等待一段时间。如果是偶发性地触发了限流，那么稍微阻塞等待一会儿，后面就有极大的概率能得到处理。比如说限流设置为一秒钟 100 个请求，恰好来了 101 个请求。多出来的一个请求只需要等一秒钟，下一秒钟就会被处理。但是要注意控制住超时，也就是说你不能让人无限期地等待下去。


• 同步转异步。它是指如果一个请求没被限流，那就直接同步处理；而如果被限流了，那么这个请求就会被存储起来，等到业务低峰期的时候再处理。这个其实跟降级差不多。


• 调整负载均衡算法。如果某个请求被限流了，那么就相当于告诉负载均衡器，应该尽可能少给这个节点发送请求。

亮点

突发流量

漏桶算法非常均匀，但是令牌桶相比之下就没那么均匀。令牌桶本身允许积攒一部分令牌，所以如果有偶发的突发流量，那么这一部分请求也能得到正常处理。但是要小心令牌桶的容量，不能设置太大。不然积攒的令牌太多的话就起不到限流效果了。例如容量设置为 1000，那么要是积攒了 1000 个令牌之后真的突然来了 1000 个请求，它们都能拿到令牌，那么系统可能撑不住这突如其来的 1000 个请求。

请求大小

如果面试官问到为什么使用了限流，系统还是有可能崩溃，或者你在负载均衡里面聊到了请求大小的问题，都可以这样来回答，关键词是请求大小。

限流和负载均衡有点儿像，基本没有考虑请求的资源消耗问题。所以负载均衡不管怎么样，都会有偶发性负载不均衡的问题，限流也是如此。例如即便我将一个实例限制在每秒 100 个请求，但是万一这个 100 个请求都是消耗资源很多的请求，那么最终这个实例也可能会承受不住负载而崩溃。动态限流算法一定程度上能够缓解这个问题，但是也无法根治，因为一个请求只有到它被执行的时候，我们才知道它是不是大请求。

计算阈值

总体上思路有四个：看服务的观测数据、压测、借鉴、手动计算。

看服务的性能数据属于常规解法，基本上就是看业务高峰期的 QPS 来确定整个集群的阈值。如果要确定单机的阈值，那就再除以实例个数。所以你可以这样来回答，关键词是业务性能数据。

我们公司有完善的监控，所以我可以通过观测到的性能数据来确定阈值。比如说观察线上的数据，如果在业务高峰期整个集群的 QPS 都没超过 1000，那么就可以考虑将阈值设定在 1200，多出来的 200 就是余量。 不过这种方式有一个要求，就是服务必须先上线，有了线上的观测数据才能确定阈值。并且，整个阈值很有可能是偏低的。因为业务巅峰并不意味着是集群性能的瓶颈。如果集群本身可以承受每秒 3000 个请求，但是因为业务量不够，每秒只有 1000 个请求，那么我这里预估出来的阈值是显著低于集群真实瓶颈 QPS 的。

压测

不过我个人觉得，最好的方式应该是在线上执行全链路压测，测试出瓶颈。即便不能做全链路压测，也可以考虑模拟线上环境进行压测，再差也应该在测试环境做一个压力测试。

从理论上来说，你可以选择 A、B、C 当中的任何一个点作为你的限流的阈值。

A 是性能最好的点。A 之前 QPS 虽然在上升，但是响应时间稳定不变。在这个时候资源利用率也在提升，所以选择 A 你可以得到最好的性能和较高的资源利用率。

B 是系统快要崩溃的临界点。很多人会选择这个点作为限流的阈值。这个点响应时间已经比较长了，但是系统还能撑住。选择这个点意味着能撑住更高的并发，但是性能不是最好的，吞吐量也不是最高的。

C 是吞吐量最高的点。实际上，有些时候你压测出来的 B 和 C 可能对应到同一个 QPS 的值。选择这个点作为限流阈值，你可以得到最好的吞吐量。

性能 A、并发 B、吞吐量 C。

无法压测：

不过如果真的做不了，或者来不及，或者没资源，那么还可以考虑参考类似服务的阈值。比如说如果 A、B 服务是紧密相关的，也就是通常调用了 A 服务就会调用 B 服务，那么可以用 A 已经确定的阈值作为 B 的阈值。又或者 A 服务到 B 服务之间有一个转化关系。比如说创建订单到支付，会有一个转化率，假如说是 90%，如果创建订单的接口阈值是 100，那么支付的接口就可以设置为 90。

如果我这是一个全新的业务呢？也就是说，你都没得借鉴。这个时候就只剩下最后一招了——手动计算。

实在没办法了，就只能手动计算了。也就是沿着整条调用链路统计出现了多少次数据库查询、多少次微服务调用、多少次第三方中间件访问，如 Redis，Kafka 等。举一个最简单的例子，假如说一个非常简单的服务，整个链路只有一次数据库查询，这是一个会回表的数据库查询，根据公司的平均数据这一次查询会耗时 10ms，那么再增加 10 ms 作为 CPU 计算耗时。也就是说这一个接口预期的响应时间是 20ms。如果一个实例是 4 核，那么就可以简单用 1000ms÷10ms×4=400 得到阈值。

手动计算准确度是很差的。比如说垃圾回收类型语言，还要刨除垃圾回收的开销，相当于 400 打个折扣。折扣多大又取决于你的垃圾回收频率和消耗。

升华：

最好还是把阈值做成可以动态调整的。那么在最开始上线的时候就可以把阈值设置得比较小。后面通过观测发现系统还很健康，就可以继续上调阈值。

此文章为9月Day25学习笔记，内容来源于极客时间《后端工程师的高阶面经》

前言

今天摸鱼逛知乎，偶然看到了一个回答，8月份的，是关于SaToken的，一时好奇就点了进去。

好家伙，因为一个star的问题，提问的人抱怨了许多，我有些意外，就仔细看了下面的评论，想知道一部分人的看法。

案发现场

大体上，分为两派。

一派是对于强制star尤为反感，乃至因爱生恨(打个问号)？

比如下面这种，狂喷作者的。当我看到所谓“花几个工作日自己也能撸一个”这句话的时候，差点没忍住把酱香拿铁喷在电脑上。

本想敲几个字对垒下，但我好歹也是知乎认证的号，想想算了，没必要和这种人打口水仗。

还有一些是拿数据指责Sa-Token，以及搬出Spring Security做对比的，字里行间一股子微博的味道。

总而言之，反感这种强制star的人，我发现他们是内心真的极其反感，就像是自己被作者抛弃了一样。

后面喷着喷着，拔出萝卜带出泥，好吧，ruoyi也被拉出来示众了，这味儿太冲了。

当然，另一派就是持不同看法的，里面有一句话总结的倒是挺有意思。

说到这里，其实Sa-Token的作者也亲自下场做了一些解释，比如解释不想star可以如何做，这一点我觉得略显牵强，但后面也给了别的解决方式，听取了部分评论者的中肯意见。

重要的是，作者最后的回答，就像是无声地呐喊，也许很多喷子接受不了这种呐喊，因为这个“孩子”不是他们的，别人家的孩子跟我有什么关系。

国内开源现状

通过这个事情，其实勾起了我一些回忆，可能年轻点的程序员是不了解的，国内的开源生态以前是个什么情况。

像我这样年纪稍微大点的可能就见过那个过程，说白了，就是来一批死一批。

没错，国内开源生态就是个充满病菌的牧场，里面养了一群牛羊，结局是大多都病死了，真正能上餐桌的却没几个。

还有人记得当年开源生态圈很离谱的一件事情吗，XXL-JOB的作者发帖伸冤，因为自己的开源项目竟然被某个互联网公司拿去申请了软著。

等于说一个花费心力的项目，仅仅因为开源协议被钻了漏洞，就直接成别人的了，作者没办法只能在网上伸冤求助，以及找开源中国出面解决。

为什么这些公司敢这么做，换成你是作者你接受得了么，你有信心以个人的力量对抗事先有准备的这些打擦边球的侵权么。

因为国内的开源生态就是病态的、畸形的，那几年国内开源项目如雨后春笋，绝大部分作者根本还没有较高的经营意识，凭的就是一腔热爱分享的情怀，以及对拥有自己的一个开源项目这件事的热忱。

然后因为不懂法律，被钻空子，竹篮打水一场空，这样的案例出现一个，就会引起寒蝉效应，开源作者人人自危，谁还敢用授权范围更大的协议。

树上有七只鸟，打死了一只，还剩几只？

然后，再举例说一下上面截图中有喷子提到的ruoyi。

我想问问，现在有多少Java程序员是一路看着ruoyi走过来的。

我猜不多，就算有，也是中途上车的。

我可以简单说下ruoyi当初的处境，虽然只是一个后台管理的项目，我是真没想到时隔多年作者竟然还在写。

当初围绕在ruoyi身边的是一大堆出色的后台管理项目，各具特色，不少都比它要火，但最后具备代表性的只剩ruoyi了。

因为作者一直在迭代，我记得第一次看到ruoyi的时候，作者还写着项目名称的描述，是想象自己未来女儿的名字，所以起了若依。

能坚持这么多年不停歇，那些年你也根本别想凭着开源项目赚什么钱，估计连你工资的零头都没有，但人家还是能迭代到现在。

我就想着，单纯寻思着，也该到了人家收获果实的季节了吧。

我是打心里佩服这些人的，我没觉得比别人差，有些项目花时间我也能写，问题是，我做不到啊，你呢。

总结

如果有一个同行写了开源项目，他想挣钱，我支持，但是项目越来越烂，我会离开，后会无期。

如果有一个同行写了开源项目，他想挣钱，我支持，但是项目越来越好，我会分享，也会付钱。

当我们不断坚持追求，最终换来真正感人的回报，何尝不是生命中最美妙的旋律。

我真诚希望给国内优秀的开源作者更多能挣钱的空间，让那些项目越来越好。

这是我对那些当初“死去”的开源作者的缅怀，也是对未来更多开源作者的殷切期待。

以上纯属个人看法，不收钱的，轻点喷。

如果喜欢，请点赞+关注↑↑↑，持续分享干货和行业动态哦~

早前搭过一个wiki (可点击wiki.dashen.tech 查看),用于"团队协作与知识分享".把游客账号给一位前同事,其告知登录出错.

用我记录的账号密码登录,同样报错; 打开数据库一看,疑惑全消.

To recover your lost Database and avoid leaking it: Send us 0.05 Bitcoin (BTC) to our Bitcoin address 3F4hqV3BRYf9JkPasL8yUPSQ5ks3FF3tS1 and contact us by Email with your Server IP or Domain name and a Proof of Payment. Your Database is downloaded and backed up on our servers. Backups that we have right now: mm_wiki, shuang. If we dont receive your payment in the next 10 Days, we will make your database public or use them otherwise.

(按照今日比特币价格,0.05比特币折合人民币4 248.05元..)

大多时候不使用该服务器上安装的mysql,因而账号和端口皆为默认,密码较简单且常见,为在任何地方navicat也可连接,去掉了ip限制...对方写一个脚本,扫描各段ip地址,用常见的几个账号和密码去"撞库",几千几万个里面,总有一两个能得手.

被窃取备份而后删除的两个库,一个是来搭建该wiki系统,另一个是用来亲测mysql主从同步,详见此篇,价值都不大

实践告诉我们，不要用默认账号，不要用简单密码，要做ip限制。…

• 登录服务器,登录到mysql:

mysql -u root -p

• 修改密码:

尝试使用如下语句来修改

set password for 用户名@yourhost = password('新密码');

结果报错;查询得知是最新版本更改了语法,需用

alter user 'root'@'localhost' identified by 'yourpassword';

成功~

但在navicat里,原连接依然有效,而输入最新的密码,反倒是失败

打码部分为本机ip

在服务器执行

-- 查询所有用户

select user from mysql.user;

再执行

select host,user,authentication_string from mysql.user;

user及其后的host组合在一起,才构成一个唯一标识;故而在user表中,可以存在同名的root

使用

alter user 'root'@'%' identified by 'xxxxxx';

注意主机此处应为%

再使用

select host,user,authentication_string from mysql.user;

发现 "root@%" 对应的authentication_string已发生改变;

在navicat中旧密码已失效,需用最新密码才可登录

参考:

mysql 5.7 修改用户密码

关于修改账号,可参考此

这不是第一次遭遇"比特币勒索",在四月份,收到了这么一封邮件:

后来证明这是唬人的假消息,但还是让我学小扎,把Mac的摄像头覆盖了起来..

引子

话说新房子装修，安装了遥遥领先智能门锁PRO，最近到了家具进场的阶段。

某日，接到一通电话：“哥，你现在家里有人吗？你的书桌到了。”

原来是快递小哥，我回复他：“家里没人，但是有智能锁，嗯，因为临时密码有时间限制，等下到了再给我回下电话，我把临时密码给你。”

“好嘞，那到时候联系”

挂断电话，我随手打开手机上的花粉生活APP，但是感觉有点不对劲，我去，设备咋都离线了(后来发现是网络欠费)？我顿时虎躯一震，脑海中浮现了快递小哥到了后发现自己白跑一趟，带着满头大汗、气喘吁吁并且嘴里一顿C语言输出的尴尬场景...

但是我惊喜的发现，门锁的卡片虽然离线但还可以正常进入，我抱着试一试的心态点进去，临时密码竟然可以正常生成，真牛！

于是我点击了生成临时密码...

电话又响起：“哥我到了，把密码给我吧”

我将临时密码给小哥开了门，一切顺利...

实现

这是前段时间亲身经历的一件事，原本以为智能门锁临时密码的功能需要网络支持，服务器生成临时密码给用户，同时下发到门锁里面。现在发现，并不需要门锁联网也可以执行密码验证的操作。
脑海中思考了下，临时密码离线验证这个功能可能是类似这样实现的：

• 门锁端和服务器端采用相同的规则生成临时密码，并且密码生成规则里面包含了时间这个因素


• 用户请求临时密码，服务端按照规则生成临时密码返回给用户


• 用户输入临时密码解锁，门锁按照同样的规则进行校验
  以上实现是一个直觉性的思考，实际编码落地根据不同的需求会有更多的考虑，以我在使用的遥遥领先牌智能门锁Pro为例，下面来做一个简单的实现...

首先，让来看看这款门锁的临时密码有哪些限制条件：

限制条件有：

• 单个密码有效期为30分钟


• 有效期内只能使用一次


• 一分钟内只能添加一个临时密码

根据这些限制条件和前面的思考，密码生成规则可以这样设置：

• 拼接产品序列号+当前时间字符串，获取拼接后字符串的hashcode，然后对1000000（百万）取余，得到6位数字作为临时密码。并且时间字符串按照yyyy-MM-dd HH:mm 格式，精确到分钟


• 加入产品序列号的原因是为了让不同门锁在相同时间产生不同的密码，如果只以时间为变量肯定是不安全的


• 由于门锁生成的限制条件里面约定了一分钟只能添加一个临时密码，因此时间变量也精确到分钟，保证每分钟的临时密码不同，分钟内相同。

然后是实现思路：

• 用户请求服务端，服务端根据密码生成规则返回一个临时密码


• 快递小哥拿着临时密码在门锁现场输入


• 门锁按照临时密码输入的时间点，计算时间点前30分内每一分钟对应的密码，30分钟对应30个临时密码。为什么是30分钟？因为密码30分钟内有效


• 门锁将快递小哥输入的密码与生成的30个密码进行一一比对，如果有匹配的密码，说明临时密码有效


• 将输入的临时密码缓存，每次输入密码时都要去缓存里面判断临时密码是否在30分钟内使用过，如果使用过就不能开锁。为什么要判断是否30分钟内使用过？因为有效期内只能使用一次

有了以上思路，下面代码的编写工作就比较简单了，开整...

首先创建三个类：OtherTerminal、SmartLock、PasswordUtils 分别，表示其他可获取密码的终端、门锁以及跟密码相关的工具类

首先是OtherTerminal类，相当于可获取密码的终端，例如我们的手机或者平板，主要功能是调用PasswordUtils工具类根据门锁的序列号和当前时间来获取有效临时密码。

public class OtherTerminal {

    private final static String serialNumber = "XiaoHuaSmartLock001";

    public static void main(String[] args) {

        System.out.println("当前开锁密码："+PasswordUtils.generate(serialNumber, PasswordUtils.localDateTimeToStr(LocalDateTime.now())));

    }

}

接着是SmartLock类

SmartLock的main方法里面等待控制台的输入，并对输入的密码进行验证。验证调用了verify方法。

verify方法的执行逻辑：调用PasswordUtils工具类，获取过去30分钟内每分钟对应的临时密码，判断输入的密码是否在这些临时密码当中。如果存在说明临时密码有效，还需对当前密码在过去30分钟内是否使用进行判断，保证密码只能使用一次。这个判断是通过调用PasswordUtils工具类的getAndSet方法实现的。

如果认证成功，则开锁。否则开锁失败。

// 智能门锁

public class SmartLock {



    private final static String serialNumber = "XiaoHuaSmartLock001";

    private final static Integer expirationTime = 30;





    public static void main(String[] args) {

        // 步骤：首先生成过去30分钟内的所有数字



        Scanner scanner = new Scanner(System.in);

        while (scanner.hasNext()) {

            int password = scanner.nextInt();

            if (verify(password)) {

                System.out.println("开锁成功，当前时间：" + LocalDateTime.now());

            } else {

                System.out.println("开锁失败，当前时间：" + LocalDateTime.now());

            }

        }

        scanner.close();



    }



    private static boolean verify(Integer inputPassword) {

        // 获取当前时间点以前30分钟内的所有密码

        LocalDateTime now = LocalDateTime.now();

        LocalDateTime validityPeriod = now.minusMinutes(expirationTime);

        List<Integer> validityPeriodPasswords = new ArrayList<>();



        while (validityPeriod.isBefore(now.plusMinutes(1L))) {

            validityPeriodPasswords.add(PasswordUtils.generate(serialNumber, PasswordUtils.localDateTimeToStr(validityPeriod)));

            validityPeriod = validityPeriod.plusMinutes(1L);

        }

        System.out.println(validityPeriodPasswords);

        return validityPeriodPasswords.contains(inputPassword) && PasswordUtils.getAndSet(inputPassword);

    }

}

再来看下PasswordUtils工具类，这个类内容较多，分步解释：
首先是生成6位临时密码的generate方法，比较简单。但是这样生成的密码不能以0开头，是缺点！

/**

 * 生成一个密码

 *

 * @return 返回一个六位正整数

 */

public static Integer generate(String serialNumber, String time) {

    String toHash = time + serialNumber;

    return Math.abs(toHash.hashCode() % 1000000);

}

接着是一个格式化时间的方法，将时间格式化为：yyyy-MM-dd HH:mm。精确到分钟，generate方法的第二个参数time需要调用此方法来保证时间以分钟为单位，这样分钟内生成的密码都是相同的

public static String localDateTimeToStr(LocalDateTime localDateTime) {

    DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm");

    return formatter.format(localDateTime);

}

最后是门锁对临时密码的管理：

• 临时密码存储在一个map对象中：usedPasswordMap


• 有一个标记对象clearTag用于标记是否应当对usedPasswordMap进行清理操作，用于清理已过期的临时密码


• 临时密码存在时间大于30分钟，判断为已过期

下面是临时密码过期判断和过期清理的方法

/**

 * @param current 当前时间

 * @param compare 比较时间

 * @return 是否过期

 */

private static boolean expired(long current, long compare) {

    Instant endInstant = Instant.ofEpochMilli(current);

    LocalDateTime end = LocalDateTime.ofInstant(endInstant, ZoneId.systemDefault());

    Instant beginInstant = Instant.ofEpochMilli(compare);

    LocalDateTime begin = LocalDateTime.ofInstant(beginInstant, ZoneId.systemDefault());



    Duration duration = Duration.between(begin, end);

    long actualInterval = switch (PasswordUtils.expirationUnit) {

        case SECONDS -> duration.toSeconds();

        case MINUTES -> duration.toMinutes();

        case HOURS -> duration.toHours();

        case DAYS -> duration.toDays();

        default -> throw new IllegalArgumentException("输入时间类型不支持");

    };

    return actualInterval >= (long) PasswordUtils.expirationTime;

}



/**

 * 清理过期的密码

 */

private static void clearExpired() {

    Iterator<Map.Entry<Integer, Long>> iterator = usedPasswordMap.entrySet().iterator();

    Long currentTimestamp = System.currentTimeMillis();

    while (iterator.hasNext()) {

        Map.Entry<Integer, Long> item = iterator.next();

        if (expired(currentTimestamp, item.getValue())) {

            iterator.remove();

        }

    }

}

getAndSet方法：

• 首先判断是否达到了清理阈值，从而执行是否清理的操作,用于节省资源消耗


• 从usedPasswordMap中获取当前输入密码是否存在，如果不存在说明密码未使用过，则将当前密码设置到map里面并返回true，否则还要进行进一步的判断，因为可能存在历史密码但是已过期和当前密码重复的情况


• 若usedPasswordMap中存在当前密码，调用expired方法，如果历史密码过期了说明当前密码有效，并刷新时间戳，否则说明有效期内当前密码已经使用过一次

/**

 *

 * @param password

 * @return false说明密码已经使用过，true则表示密码可以使用

 */

public static boolean getAndSet(Integer password) {

    // usedPasswordMap存储的过期密码可能会越来越多，需要定期清理

    if (clearTag > clearThreshold) {

        if (!usedPasswordMap.isEmpty()) {

            clearExpired();

        }

        clearTag = 0;

    }

    clearTag++;

    Long usedPasswordTimestamp = usedPasswordMap.get(password);

    Long currentTimestamp = System.currentTimeMillis();

    if (ObjectUtils.isEmpty(usedPasswordTimestamp)) {

        usedPasswordMap.put(password, currentTimestamp);

        return true;

    }

    // 到了这里说明密码已经使用过(有效期内，或之前)，若使用时间距今在有效期内，说明当期已经使用过，否则是以前使用的

    if (expired(currentTimestamp, usedPasswordTimestamp)) {

        usedPasswordMap.put(password, currentTimestamp);

        System.out.println("密码虽然已使用，但为历史使用，因此当前密码有效");

        return true;

    }

    System.out.println("密码有效期内已使用一次");

    return false;

}

验证

我将门锁程序部署到我的服务器上面，并运行。随便输入一个数字，例如123456，返回开锁失败。

然后本地运行OtherTerminal类获取临时密码：974971

再去门锁上验证试试：开锁成功！

最后完整的PasswordUtil工具类的代码贴在这里：

// 密码工具类



public class PasswordUtils {

    private static Map<Integer, Long> usedPasswordMap = new HashMap<>();

    private final static Integer expirationTime = 30;

    private final static TimeUnit expirationUnit = TimeUnit.MINUTES;

    private final static Integer clearThreshold = 30;

    private static Integer clearTag = 0;



    /**

     * 获取code状态，并设置到使用code里面

     *

     * @param password

     * @return false说明密码已经使用过，true则表示密码可以使用

     */

    public static boolean getAndSet(Integer password) {

        // usedPasswordMap存储的过期密码可能会越来越多，需要定期清理

        if (clearTag > clearThreshold) {

            if (!usedPasswordMap.isEmpty()) {

                clearExpired();

            }

            clearTag = 0;

        }

        clearTag++;

        Long usedPasswordTimestamp = usedPasswordMap.get(password);

        Long currentTimestamp = System.currentTimeMillis();

        if (ObjectUtils.isEmpty(usedPasswordTimestamp)) {

            usedPasswordMap.put(password, currentTimestamp);

            return true;

        }

        // 到了这里说明密码已经使用过(有效期内，或之前)，若使用时间距今在有效期内，说明当期已经使用过，否则是以前使用的

        if (expired(currentTimestamp, usedPasswordTimestamp)) {

            usedPasswordMap.put(password, currentTimestamp);

            System.out.println("密码虽然已使用，但为历史使用，因此当前密码有效");

            return true;

        }

        System.out.println("密码有效期内已使用一次");

        return false;

    }





    /**

     * @param current 当前时间

     * @param compare 比较时间

     * @return 是否过期

     */

    private static boolean expired(long current, long compare) {

        Instant endInstant = Instant.ofEpochMilli(current);

        LocalDateTime end = LocalDateTime.ofInstant(endInstant, ZoneId.systemDefault());

        Instant beginInstant = Instant.ofEpochMilli(compare);

        LocalDateTime begin = LocalDateTime.ofInstant(beginInstant, ZoneId.systemDefault());



        Duration duration = Duration.between(begin, end);

        long actualInterval;

        switch (PasswordUtils.expirationUnit) {

            case SECONDS:

                actualInterval = duration.toSeconds();

                break;

            case MINUTES:

                actualInterval = duration.toMinutes();

                break;

            case HOURS:

                actualInterval = duration.toHours();

                break;

            case DAYS:

                actualInterval = duration.toDays();

                break;

            default:

                throw new IllegalArgumentException("输入时间类型不支持");

        }

        return actualInterval >= (long) PasswordUtils.expirationTime;

    }



    /**

     * 清理过期的密码

     */

    private static void clearExpired() {

        Iterator<Map.Entry<Integer, Long>> iterator = usedPasswordMap.entrySet().iterator();

        Long currentTimestamp = System.currentTimeMillis();

        while (iterator.hasNext()) {

            Map.Entry<Integer, Long> item = iterator.next();

            if (expired(currentTimestamp, item.getValue())) {

                iterator.remove();

            }

        }

    }



    /**

     * 生成一个密码

     *

     * @return 返回一个六位正整数

     */

    public static Integer generate(String serialNumber, String time) {

        String toHash = time + serialNumber;

        return Math.abs(toHash.hashCode() % 1000000);

    }



    public static String localDateTimeToStr(LocalDateTime localDateTime) {

        DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm");

        return formatter.format(localDateTime);

    }



}

最后的最后，这种方法生成的密码有个bug，就是30分钟内生成的30个密码里面会有重复的可能性，不过想来发生概率很低，看后续如何优化了。

1.背景

最近刷抖音发现上线了 IP 属地的功能，小伙伴在发表动态、发表评论以及聊天的时候，都会显示自己的 IP 属地信息，其核心意义是让用户更具有真实性，减少虚假欺骗事件。正好最近本人开发获取客户端ip，做一些接口限流，黑白名单等需求功能，顺路就研究了一下怎么解析IP获取归属地问题。

接下来，就着重讲解一下Java后端怎么实现IP归属地的功能，其实只需要以下两大步骤：

2.获取客户端ip接口

做过web开发都知道，无论移动端还是pc端的请求接口都会被封装成为一个HttpServletRequest对象，该对象包含了客户端请求信息包括请求的地址，请求的参数，提交的数据等等。

如果服务器直接把IP暴漏出去，那么request.getRemoteAddr()就能拿到客户端ip。

但目前流行的架构中，基本上服务器都不会直接把自己的ip暴漏出去，一般前面还有一层或多层反向代理，常见的nginx居多。 加了代理后，相当于服务器和客户端中间还有一层，这时·request.getRemoteAddr()拿到的就是代理服务器的ip了，并不是客户端的ip。所以这种情况下，一般会在转发头上加X-Forwarded-For等信息，用来跟踪原始客户端的ip。

X-Forwarded-For： 这是一个 Squid 开发的字段，只有在通过了HTTP代理或者负载均衡服务器时才会添加该项。 格式为X-Forwarded-For:client1,proxy1,proxy2，一般情况下，第一个ip为客户端真实ip，后面的为经过的代理服务器ip。 上面的代码注释也说的很清楚，直接截取拿到第一个ip。 Proxy-Client-IP/WL- Proxy-Client-IP： 这个一般是经过apache http服务器的请求才会有，用apache http做代理时一般会加上Proxy-Client-IP请求头，而WL-Proxy-Client-IP是他的weblogic插件加上的头。这种情况也是直接能拿到。 HTTP_CLIENT_IP： 有些代理服务器也会加上此请求头。 X-Real-IP： nginx一般用这个。

但是在日常开发中，并没有规范规定用以上哪一个头信息去跟踪客户端，所以都有可能，只能一一尝试，直到获取到为止。代码如下：

@Slf4j

public class IpUtils {

​

    private static final String UNKNOWN_VALUE = "unknown";

    private static final String LOCALHOST_V4 = "127.0.0.1";

    private static final String LOCALHOST_V6 = "0:0:0:0:0:0:0:1";

​

    private static final String X_FORWARDED_FOR = "X-Forwarded-For";

    private static final String X_REAL_IP = "X-Real-IP";

    private static final String PROXY_CLIENT_IP = "Proxy-Client-IP";

    private static final String WL_PROXY_CLIENT_IP = "WL-Proxy-Client-IP";

    private static final String HTTP_CLIENT_IP = "HTTP_CLIENT_IP";

​

    private static final String IP_DATA_PATH = "/Users/shepherdmy/Desktop/ip2region.xdb";

    private static  byte[] contentBuff;

  

   /**

     * 获取客户端ip地址

     * @param request

     * @return

     */

    public static String getRemoteHost(HttpServletRequest request) {

        String ip = request.getHeader(X_FORWARDED_FOR);

        if (StringUtils.isNotEmpty(ip) && !UNKNOWN_VALUE.equalsIgnoreCase(ip)) {

            // 多次反向代理后会有多个ip值，第一个ip才是真实ip

            int index = ip.indexOf(",");

            if (index != -1) {

                return ip.substring(0, index);

            } else {

                return ip;

            }

        }

        ip = request.getHeader(X_REAL_IP);

        if (StringUtils.isNotEmpty(ip) && !UNKNOWN_VALUE.equalsIgnoreCase(ip)) {

            return ip;

        }

        if (StringUtils.isBlank(ip) || UNKNOWN_VALUE.equalsIgnoreCase(ip)) {

            ip = request.getHeader(PROXY_CLIENT_IP);

        }

        if (StringUtils.isBlank(ip) || UNKNOWN_VALUE.equalsIgnoreCase(ip)) {

            ip = request.getHeader(WL_PROXY_CLIENT_IP);

        }

        if (StringUtils.isBlank(ip) || UNKNOWN_VALUE.equalsIgnoreCase(ip)) {

            ip = request.getRemoteAddr();

        }

​

        if (StringUtils.isBlank(ip) || UNKNOWN_VALUE.equalsIgnoreCase(ip)) {

            ip = request.getHeader(HTTP_CLIENT_IP);

        }

​

        if (StringUtils.isBlank(ip) || UNKNOWN_VALUE.equalsIgnoreCase(ip)) {

            ip = request.getRemoteAddr();

        }

        return ip.equals(LOCALHOST_V6) ? LOCALHOST_V4 : ip;

    }

​

 }

项目推荐：基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba企业级系统架构底层框架封装，解决业务开发时常见的非功能性需求，防止重复造轮子，方便业务快速开发和企业技术栈框架统一管理。引入组件化的思想实现高内聚低耦合并且高度可配置化，做到可插拔。严格控制包依赖和统一版本管理，做到最少化依赖。注重代码规范和注释，非常适合个人学习和企业使用

Github地址：github.com/plasticene/…

Gitee地址：gitee.com/plasticene3…

微信公众号：Shepherd进阶笔记

交流探讨群：Shepherd_126

3.获取ip归属地

通过上面我们就能获取到客户端用户的ip地址，接下来就可以通过ip解析获取归属地了。

如果我们在网上搜索资料教程，大部分都是说基于各大平台(eg:淘宝，新浪)提供的ip库进行查询，不过不难发现这些平台已经不怎么维护这个功能，现在处于“半死不活”的状态，根本不靠谱，当然有些平台提供可靠的获取ip属地接口，但是收费、收费、收费。

本着作为一个程序员的严谨：“能白嫖的就白嫖，避免出现要买的是你，不会用也是你的尴尬遭遇”。扯远了言归正传，为了寻求可靠有效的解决方案，只能去看看github有没有什么项目能满足需求，果然功夫不负有心人，发现一个宝藏级项目：ip2region，一个准确率 99.9% 的离线 IP 地址定位库，0.0x 毫秒级查询，ip2region.db 数据库只有数 MB的项目，提供了众多主流编程语言的 xdb 数据生成和查询客户端实现，这里只能说：开源真香，开源万岁。

3.1 Ip2region 特性

标准化的数据格式

每个 ip 数据段的 region 信息都固定了格式：国家|区域|省份|城市|ISP，只有中国的数据绝大部分精确到了城市，其他国家部分数据只能定位到国家，其余选项全部是0。

数据去重和压缩

xdb 格式生成程序会自动去重和压缩部分数据，默认的全部 IP 数据，生成的 ip2region.xdb 数据库是 11MiB，随着数据的详细度增加数据库的大小也慢慢增大。

极速查询响应

即使是完全基于 xdb 文件的查询，单次查询响应时间在十微秒级别，可通过如下两种方式开启内存加速查询：

0. vIndex 索引缓存 ：使用固定的 512KiB 的内存空间缓存 vector index 数据，减少一次 IO 磁盘操作，保持平均查询效率稳定在10-20微秒之间。


1. xdb 整个文件缓存：将整个 xdb 文件全部加载到内存，内存占用等同于 xdb 文件大小，无磁盘 IO 操作，保持微秒级别的查询效率。

IP 数据管理框架

v2.0 格式的 xdb 支持亿级别的 IP 数据段行数，region 信息也可以完全自定义，例如：你可以在 region 中追加特定业务需求的数据，例如：GPS信息/国际统一地域信息编码/邮编等。也就是你完全可以使用 ip2region 来管理你自己的 IP 定位数据。

99.9% 准确率

数据聚合了一些知名 ip 到地名查询提供商的数据，这些是他们官方的的准确率，经测试着实比经典的纯真 IP 定位准确一些。

ip2region 的数据聚合自以下服务商的开放 API 或者数据（升级程序每秒请求次数 2 到 4 次）：

• 01，>80%，淘宝IP地址库，ip.taobao.com/%5C


• 02，≈10%，GeoIP，geoip.com/%5C


• 03，≈2%，纯真 IP 库，http://www.cz88.net/%5C

备注：如果上述开放 API 或者数据都不给开放数据时 ip2region 将停止数据的更新服务。

3.2 整合Ip2region客户端进行查询

提供了众多主流编程语言的 xdb 数据生成和查询客户端实现，已经集成的客户端有：java、C#、php、c、python、nodejs、php扩展（php5 和 php7）、golang、rust、lua、lua_c，nginx。这里讲一下java的客户端。

首先我们需要引入依赖：

<dependency>

  <groupId>org.lionsoul</groupId>

  <artifactId>ip2region</artifactId>

  <version>2.6.5</version>

</dependency>

接下来我们需要先去下载数据文件ip2region.xdb到本地，然后基于数据文件进行查询，下面查询方法文件路径改为你本地路径即可，ip2region提供三种查询方式：

完全基于文件的查询

import org.lionsoul.ip2region.xdb.Searcher;

import java.io.*;

import java.util.concurrent.TimeUnit;

​

public class SearcherTest {

    public static void main(String[] args) {

        // 1、创建 searcher 对象

        String dbPath = "ip2region.xdb file path";

        Searcher searcher = null;

        try {

            searcher = Searcher.newWithFileOnly(dbPath);

        } catch (IOException e) {

            System.out.printf("failed to create searcher with `%s`: %s\n", dbPath, e);

            return;

        }

​

        // 2、查询

        try {

            String ip = "1.2.3.4";

            long sTime = System.nanoTime();

            String region = searcher.search(ip);

            long cost = TimeUnit.NANOSECONDS.toMicros((long) (System.nanoTime() - sTime));

            System.out.printf("{region: %s, ioCount: %d, took: %d μs}\n", region, searcher.getIOCount(), cost);

        } catch (Exception e) {

            System.out.printf("failed to search(%s): %s\n", ip, e);

        }

​

        // 3、关闭资源

        searcher.close();

        

        // 备注：并发使用，每个线程需要创建一个独立的 searcher 对象单独使用。

    }

}

缓存 VectorIndex 索引

我们可以提前从 xdb 文件中加载出来 VectorIndex 数据，然后全局缓存，每次创建 Searcher 对象的时候使用全局的 VectorIndex 缓存可以减少一次固定的 IO 操作，从而加速查询，减少 IO 压力。

import org.lionsoul.ip2region.xdb.Searcher;

import java.io.*;

import java.util.concurrent.TimeUnit;

​

public class SearcherTest {

    public static void main(String[] args) {

        String dbPath = "ip2region.xdb file path";

​

        // 1、从 dbPath 中预先加载 VectorIndex 缓存，并且把这个得到的数据作为全局变量，后续反复使用。

        byte[] vIndex;

        try {

            vIndex = Searcher.loadVectorIndexFromFile(dbPath);

        } catch (Exception e) {

            System.out.printf("failed to load vector index from `%s`: %s\n", dbPath, e);

            return;

        }

​

        // 2、使用全局的 vIndex 创建带 VectorIndex 缓存的查询对象。

        Searcher searcher;

        try {

            searcher = Searcher.newWithVectorIndex(dbPath, vIndex);

        } catch (Exception e) {

            System.out.printf("failed to create vectorIndex cached searcher with `%s`: %s\n", dbPath, e);

            return;

        }

​

        // 3、查询

        try {

            String ip = "1.2.3.4";

            long sTime = System.nanoTime();

            String region = searcher.search(ip);

            long cost = TimeUnit.NANOSECONDS.toMicros((long) (System.nanoTime() - sTime));

            System.out.printf("{region: %s, ioCount: %d, took: %d μs}\n", region, searcher.getIOCount(), cost);

        } catch (Exception e) {

            System.out.printf("failed to search(%s): %s\n", ip, e);

        }

        

        // 4、关闭资源

        searcher.close();

​

        // 备注：每个线程需要单独创建一个独立的 Searcher 对象，但是都共享全局的制度 vIndex 缓存。

    }

}

缓存整个 xdb 数据

我们也可以预先加载整个 ip2region.xdb 的数据到内存，然后基于这个数据创建查询对象来实现完全基于文件的查询，类似之前的 memory search。

import org.lionsoul.ip2region.xdb.Searcher;

import java.io.*;

import java.util.concurrent.TimeUnit;

​

public class SearcherTest {

    public static void main(String[] args) {

        String dbPath = "ip2region.xdb file path";

​

        // 1、从 dbPath 加载整个 xdb 到内存。

        byte[] cBuff;

        try {

            cBuff = Searcher.loadContentFromFile(dbPath);

        } catch (Exception e) {

            System.out.printf("failed to load content from `%s`: %s\n", dbPath, e);

            return;

        }

​

        // 2、使用上述的 cBuff 创建一个完全基于内存的查询对象。

        Searcher searcher;

        try {

            searcher = Searcher.newWithBuffer(cBuff);

        } catch (Exception e) {

            System.out.printf("failed to create content cached searcher: %s\n", e);

            return;

        }

​

        // 3、查询

        try {

            String ip = "1.2.3.4";

            long sTime = System.nanoTime();

            String region = searcher.search(ip);

            long cost = TimeUnit.NANOSECONDS.toMicros((long) (System.nanoTime() - sTime));

            System.out.printf("{region: %s, ioCount: %d, took: %d μs}\n", region, searcher.getIOCount(), cost);

        } catch (Exception e) {

            System.out.printf("failed to search(%s): %s\n", ip, e);

        }

        

        // 4、关闭资源 - 该 searcher 对象可以安全用于并发，等整个服务关闭的时候再关闭 searcher

        // searcher.close();

​

        // 备注：并发使用，用整个 xdb 数据缓存创建的查询对象可以安全的用于并发，也就是你可以把这个 searcher 对象做成全局对象去跨线程访问。

    }

}

3.3 springboot整合示例

首先我们也需要像上面一样引入maven依赖。然后就可以基于上面的查询方式进行封装成工具类了，我这里选择了上面的第三种方式：缓存整个 xdb 数据

@Slf4j

public class IpUtils {

    private static final String IP_DATA_PATH = "/Users/shepherdmy/Desktop/ip2region.xdb";

    private static  byte[] contentBuff;

​

    static {

        try {

            // 从 dbPath 加载整个 xdb 到内存。

            contentBuff = Searcher.loadContentFromFile(IP_DATA_PATH);

        } catch (IOException e) {

            e.printStackTrace();

        }

    }

  

      /**

     * 根据ip查询归属地，固定格式：中国|0|浙江省|杭州市|电信

     * @param ip

     * @return

     */

    public static IpRegion getIpRegion(String ip) {

        Searcher searcher = null;

        IpRegion ipRegion = new IpRegion();

        try {

            searcher = Searcher.newWithBuffer(contentBuff);

            String region = searcher.search(ip);

            String[] info = StringUtils.split(region, "|");

            ipRegion.setCountry(info[0]);

            ipRegion.setArea(info[1]);

            ipRegion.setProvince(info[2]);

            ipRegion.setCity(info[3]);

            ipRegion.setIsp(info[4]);

        } catch (Exception e) {

            log.error("get ip region error: ", e);

        } finally {

            if (searcher != null) {

                try {

                    searcher.close();

                } catch (IOException e) {

                    log.error("close searcher error:", e);

                }

            }

        }

        return ipRegion;

    }

​

}

只用Tomcat，不用Nginx搭建Web服务，行不行？我曾经提出的愚蠢问题，今天详细给自己解释下，为什么必须用Nginx！

不用Nginx，只用Tomcat的Http请求流程

浏览器处理一个Http请求时，会首先通过DNS服务器找到域名关联的IP地址，然后请求到对应的IP地址。以阿里云域名管理服务为例，一个域名可以最多绑定三个IP地址，这三个IP地址需要是公网IP地址，所以首先需要在三个公网Ip服务器上部署Tomcat实例。

此时我将面临的麻烦如下

1. 由于DNS域名管理绑定的IP地址有限，最多三个，你如果想要扩容4台Tomcat，是不支持的。无法满足扩容的诉求


2. 如果你有10个服务，对应10套Tomcat集群，就需要10 * 3台公网Ip服务器。成本还是蛮高的。


3. 10个服务需要对应10个域名，分别映射到对应的Tomcat集群


4. 10个域名我花不起这个钱啊！（其实可以用二级域名配置DNS映射）


5. 公网服务器作为接入层需要有防火墙等安全管控措施，30台公网服务器，网络安全运维，我搞不定。


6. 公网IP地址需要额外从移动联通运营商或云厂商购买，30个公网IP价格并不便宜。


7. 前后端分离的情况，Tomcat无法作为静态文件服务器，只能用Nginx或Apache

以上几个问题属于成本、安全、服务扩容等方面。

如果Tomcat服务发布怎么办

Tomcat在服务发布期间是不可用的，在发布期间Http请求打到发布的服务器，就会失败。由于DNS 最多配置3台服务器，也就是发布期间是 1/3 的失败率。 我会被老板枪毙，用加特林

DNS不能自动摘掉故障的IP地址吗？

不能，DNS只是负责解析域名对应的IP地址，他并不知道对应的服务器状态，更不会知道服务器上Tomcat的状态如何。DNS只是解析IP，并没有转发Http请求，所以压根不知道哪台服务器故障率高。更无法自动摘掉IP地址。

我能手动下掉故障的IP地址吗？

这个我能，但是还是会有大量请求失败。以阿里云为例，配置域名映射时，我可以下掉对应的IP地址，但需要指定域名映射的缓存时间，默认10分钟。换句话说，就算你在上线前，摘掉了对应的IP，依然要等10分钟，所有的客户端才会拿到最新的DNS解析地址。

那么把TTL缓存时间改小，可以吗？ 可以的，但是改小了，就意味更多的请求被迫从DNS服务器拿最新的映射，整体请求耗时增加，用户体验下降！被老板发现，会骂我。

节点突然挂掉怎么办？

虽然可以在DNS管理后台手动下掉IP地址，但是节点突然宕机、Tomcat Crash等因素导致的突然故障，我是来不及下掉对应IP地址的，我只能打电话告诉老板，“线上服务崩了，你等我10分钟改点东西”。

如果这时候有个软件能 对Tomcat集群健康检查和故障重试，那就太好了。

恰好，这是 Nginx 的长处！

Nginx可以健康检查和故障重试

而Tomcat没有。

例如有两台Tomcat节点，在Nginx配置故障重试策略

upstream test {

    server 127.0.0.1:8001 fail_timeout=60s max_fails=2; # Server A

    server 127.0.0.1:8002 fail_timeout=60s max_fails=2; # Server B

}

当A节点出现 connect refused时（端口关闭或服务器挂了），说明服务不可用，可能是服务发布，也可能是服务器挂了。此时nginx会把失败的请求自动转发到B节点。 假设第二个请求 请求到A还是失败，正好累计2个失败了，那么Nginx会自动把A节点剔除存活列表 60 秒，然后继续把请求2 转发到B节点进行处理。60秒后，再次尝试转发请求到A节点…… 循环往复，直至A节点活过来……

而这一过程客户端是感知不到失败的。因为两次请求都二次转发到B节点成功处理了。客户端并不会感知到A节点的处理失败，这就是Nginx 反向代理的好处。即客户端不用直连服务端，加了个中间商，服务端的个别节点宕机或发布，对客户端都毫无影响。

而Tomcat只是Java Web容器，并不能做这些事情。

10个服务，10个Tomcat集群，就要10个域名，30个公网IP吗？

以阿里云为例，域名管理后台是可以配置二级域名映射，所以一个公网域名拆分为10个二级域名就可以了。

所以只用Tomcat，不用Nginx。需要1个公网域名，10个二级域名，30台服务器、30个公网IP。

当我和老板提出这些的时候，他跟我说：“你XX疯了，要不滚蛋、要不想想别的办法。老子没钱，你看我脑袋值几个钱，拿去换公网IP吧”。

心里苦啊，要是能有一个软件，能帮我把一个域名分别映射到30个内网IP就好了。

恰好 Nginx可以！

Nginx 虚拟主机和反向代理

例如把多个二级域名映射到不同的文件目录，例如

1. bbs.abc.com，映射到 html/bbs


2. blog.abc.com 映射到 html/blog

http {

    include       mime.types;

    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;

    server {

        listen       80;

        server_name  http://www.abc.com;

        location / {

            root   html/www;

            index  index.html index.htm;

        }

    }

   

    server {

        listen       80;

        server_name  bbs.abc.com;

        location / { 

            root   html/bbs;

            index  index.html index.htm;

        }   

    }   



    server {

        listen       80;

        server_name  blog.abc.com;

        location / { 

            root   html/blog;

            index  index.html index.htm;

        }   

    }   

}

例如把不同的二级域名或者URL路径 映射到不同的 Tomcat集群

1. 分别定义 serverGroup1、serverGroup2 两个Tomcat集群


2. 分别把路径group1、group1 反向代理到serverGroup1、serverGroup2

upstream serverGroup1 {                    # 定义负载均衡设备的ip和状态

        server 192.168.225.100:8080 ;           # 默认权重值为一

        server 192.168.225.101:8082 weight=2;   # 值越高，负载的权重越高

        server 192.168.225.102:8083 ;       

        server 192.168.225.103:8084 backup;     # 当其他非backup状态的server 不能正常工作时，才请求该server，简称热备

    }



upstream serverGroup2 {                    # 定义负载均衡设备的ip和状态

        server 192.168.225.110:8080 ;           # 默认权重值为一

        server 192.168.225.111:8080 weight=2;   # 值越高，负载的权重越高

        server 192.168.225.112:8080 ;

        server 192.168.225.113:8080 backup;     # 当其他非backup状态的server 不能正常工作时，才请求该server，简称热备

    }



    server {                                    # 设定虚拟主机配置

        listen  80;                             # 监听的端口

        server_name  picture.itdragon.com;      # 监听的地址，多个域名用空格隔开

        location /group1 {                      # 默认请求 ，后面 "/group1" 表示开启反向代理，也可以是正则表达式

           root     html;                       # 监听地址的默认网站根目录位置

           proxy_pass   http://serverGroup1;   # 代理转发

           index  index.html index.htm;         # 欢迎页面

           deny 127.0.0.1;                      # 拒绝的ip

           allow 192.168.225.133;               # 允许的ip

        }

    location /group2 {                      # 默认请求 ，后面 "/group2" 表示开启反向代理，也可以是正则表达式

           root     html;                       # 监听地址的默认网站根目录位置

           proxy_pass   http://serverGroup2;   # 代理转发

           index  index.html index.htm;         # 欢迎页面

           deny 127.0.0.1;                      # 拒绝的ip

           allow 192.168.225.133;               # 允许的ip

        }



        error_page   500 502 503 504  /50x.html;# 定义错误提示页面     

        location = /50x.html {                  # 配置错误提示页面

            root   html;

        }

    }

经过以上的教训，我再也不会犯这么愚蠢的错误了，我需要Tomcat，也需要Nginx。

当然如果钱足够多、资源无限丰富，公网IP、公网服务器、域名无限…… 服务发布，网站崩溃，无动于衷，可以不用Nginx。