人在江湖身不由己，无论是领导的亲信还是团队的边缘，都可能遇到这种情况———不得不干一件特别难以推进的事情，茫然无措，不知如何推进。每天陷入焦虑和自我怀疑中……

这种事情一般有一些共同特点。

领导往往是拍脑袋提想法，他们也不知道具体如何执行。反过来说，如果领导明确知道怎么做，能亲自指导技术方案、亲自解决关键问题，那问题就好办了，只要跟着领导冲锋陷阵就好了，就不存在烦恼了。

遇到这种棘手的事情，如果自己被夹在中间，真的非常难受啊！

今天重点聊聊领导拍脑袋、心血来潮想做的那些大事 如果让你摊上了，你该怎么做！

1、提高警惕！逆风局翻盘难！

互联网行业目前处于稳定发展期，很少会出现突然迅猛增长的业务，也很少有公司能够迅速崛起。这是整个行业的大背景。因此，我们应该对任何不确定或模糊的目标表示怀疑，因为它们更有可能成为我们的绊脚石，而不是机遇。即使在王者荣耀这样的游戏里，要逆风翻盘也很困难，更何况在工作中呢。

当领导提出一个棘手的问题时，我们应立刻警惕，这可能不是一个好的机会，而是一个陷阱。我们不应该被领导画的饼所迷惑，而是要冷静客观地思考。哪些目标和结果是难以达到的，这些目标和结果就是领导给我们画的大饼！

领导给出任务后，我们就要努力完成。通常情况下，他们会给我们一大堆任务，需要我们确认各种事情。简而言之，他们只是有个想法，而调研报告和具体实施方案就需要我们去做。

如果领导是一位优秀而谦虚的人，通常在我们完成调研后，会根据调研结果来判断这个想法是否可行。如果不可行，他们会立即放弃，而我们也不会有什么损失。

但是，一旦领导有了一个想法，肯定是希望我们来完成的，即便我们在调研后认为不可行，大多数情况下，他们也不会接受我们的结论！因此，我们的调研工作必须极度认真，如果我们认为不可行，就要清楚地阐述不可行的理由，要非常充分。

这是我们第一次逃离的机会，我们必须重视这次机会，并抓住机会。

2、积极想办法退出

对于这种模糊不靠谱的事情，能避开就避开，不要犹豫。因为这种事情往往占用大量时间，但很难取得显著的成果。对于这种时间周期长、收益低、风险高的事情，最好保持距离。

你还需要忍受巨大的机会成本

在你长期投入这种事情的过程中，如果团队接到更好的项目和需求，那肯定不会考虑你。你只能羡慕别人的机会。

因此，如果可以撤退的话，最好离开这种费力不讨好的活远远的！

子曰：吾日三省吾身，这事能不能不干，这事能不能晚点干，这事能不能推给别人干。

如何摆脱这件事呢？

2.1 借助更高优事情插入，及时抽身

例如，突然出现了一件更为紧急的事情，这就是脱身的机会。与此同时，我们也可以为领导保留一些颜面，因为随着工作的进展，领导也会意识到这件事情的意义不大，很难取得实质成果。但是，如果我们一开始就表示不再继续做这件事，那么领导可能会觉得自己的判断出了问题，失去面子。所以，我们可以寻找一个时机，给领导下台阶。

或者，突然出现了一个需求，与我们目前的重构方案存在冲突。这是一个很好的借口。重构方案和未来产品规划产生了冲突，我们应优先满足产品规划和需求。重构方案需要后续再次评估，以找到更好的解决方案。

2.2 自己规划更重要的事情，并说服领导

当你对系统优化没有想法时，不要怪领导给你找事干。

如果领导有一个系统重构的计划和目标需要你执行，但是你不想干，或者你认为这件事不靠谱。那么你可以思考一个更可行、更有效、更能带来收益的重构方案，并与领导进行汇报。如果领导认为你的计划更加重要且更具可行性，那他可能会放弃自己的想法。

这就是主动转被动的策略。这时你的技术能力将接受考验，你能提出一个更优秀的系统重构方向吗？你能提出一个更佳的系统建设方向吗？

2.3 选择更好的时机做这件事

如果领导让你去做技术重构，而这件事的优先级不如产品需求高，上下游团队也不愿意配合你，而且领导给你的人力和时间资源也不够充裕，你应该怎么办呢？可以考虑与产品需求一起进行技术重构。也就是说，边开发需求，边进行技术重构。这样做有以下好处：可以借助于产品的力量，很自然地协调上下游团队与你一同进行重构。同时也能推动测试同事进行更全面的测试。在资源上遇到的问题，也可以让产品帮助解决。

所以，技术重构最好和产品需求结合起来进行。如果技术重构规模庞大，记得一定要分阶段进行，避免因技术重构导致产品需求延期哦。

2.4 坦诚自己能力不足，暂时无法完成这件事，以后再干行不行

可以考虑向领导坦然承认自己的能力还不足以立即执行这项任务，因此提出先缓一缓，先熟悉一下这个系统的建议。我可以多做一些需求，以此来熟悉系统，然后再进行重构。

我曾经接手一个系统，领导分配给我一个非常复杂的技术重构任务。当时我并没有足够聪明，没有拒绝，而是勉强去做，结果非常不理想，还导致了线上P0级别的事故发生！

新领导告诉我，"先想清楚如何实施，再去行动。盲目地勉强上阵只会带来糟糕的结果。当你对一个系统不熟悉的时候，绝对不能尝试对其进行重构。"

先熟悉系统至少三个月到半年。再谈重构系统！

2.5 拖字诀，拖到领导不想干这件事！

拖到领导不想干的时候，就万事大吉了。

注意这是最消极的策略，运气好，拖着拖着就不用干了。但如果运气不佳，拖延只会让任务在时间上更加紧迫，而且还会招致领导的不满。

使用拖延策略很可能得罪领导，给他们留下不良的印象。

因此，在使用此策略时应谨慎行事！

2.6 退出时毫不犹豫，不要惋惜沉默成本

如果有撤退的机会，一定不要犹豫，不要为自己付出的投入感到遗憾，不要勉强继续前进，也不必试图得到明确的结果。错误的决策只会带来错误的结果。一定要及时止损。

因为我曾经犯过类似的错误，本来有机会撤退，但是考虑到已经付出了很多，想要坚持下去。幸好有一位同事更加冷静，及时制止了我。事后我反思，庆幸及时撤退，否则后果真的不敢想象啊。

3、适当焦虑

每个人都喜欢做确定性的事情，面对不确定的事情每个人都会感到焦虑。为此可能你每天都很焦虑，甚至开始对工作和与领导见面感到厌恶。之所以这个事情让你感到不适，是因为它要求你跳出舒适区。

但是，请记住，适度的焦虑是正常的。告诉自己，这并没有什么大不了的。即使做得不好，顶多被领导责备一下而已。不值得让生活充满焦虑，最重要的是保持身心健康和快乐。

当你沉浸在焦虑中时，可能会对工作和领导感到厌烦。这样一来，你可能会对和领导沟通感到反感。这种情况是可怕的，因为你需要不断和领导沟通才能了解他真正的意图。如果失去了沟通，这个事情肯定不会有好的结果。

因此，一定要保持适度的焦虑。

3.1 沟通放在第一位

面对模糊的目标和结果，你需要反复和领导沟通，逐步确认他的意图。或者在沟通中，让领导他自己逐渐确定的自己的意图。在这方面有几个技巧~

3.2 直接去工位找他

如果在线上沟通，领导回复可能慢，可能沟通不通畅。单独约会议沟通，往往领导比较忙，没空参加。所以有问题可以直接去工位找他，随时找他沟通问题。提高效率

3.3 没听懂的话让领导说清楚

平常时候领导没说清楚，无所谓，影响不大。例如普通的产品需求，领导说的不清楚没关系，找产品问清楚就行。

面对目标不明确的项目，领导的意图就十分重要。因为你除了问领导，问其他人没用。领导就是需求的提出方，你不问领导你问谁。 在这种情况下，没听懂的事情必须要多问一嘴。把领导模糊的话问清楚。

不要怕啰嗦，也不要自己瞎揣摩领导的意图。每个人的想法都不同，瞎猜没用。

3.4 放低姿态

如果领导和你说这件事不用干了，你肯定拍手叫好。很多烦恼，领导一句话，就能帮你摆平！

放低姿态就是沟通时候，该叫苦叫苦，该求助就求助，别把自己当成超人，领导提啥要求都不打折扣的行为完全没必要。可以和领导叫叫苦，可以活跃气氛，让领导多给自己点资源，包括人和时间。

说白了，就是和 领导 “撒娇”。这方面女生比较有优势，男生可能拉不下脸。之前的公司，我真见识过，事情太多，干不完，希望领导给加人，但被领导拒绝。 然后她就哭了，最后还真管用！是个女同事。

男孩子想想其他办法撒娇吧。评论区留下你们的办法！

3.5 维护几个和领导的日常话题

平常如果有机会和领导闲聊天，一定不要社交恐惧啊！ 闲聊天很能提升双方的信任关系，可以多想想几个话题。例如车、孩子、周末干啥、去哪旅游了等等。

提升了信任关系，容易在工作中和领导更加融洽。说白了就是等你需要帮忙的时候，领导会多卖你人情！

4 积极想替代方案————当领导提的想法不合理时

积极寻求替代方案，不要被领导的思路局限！引导众人朝着正确的方向前进！

不同领导的水平和对技术问题的认知不尽相同，他们注重整体大局，而员工更注重细节。这种差异导致了宏观和微观层面之间存在信息不对称，再加上个人经验、路径依赖导致的个人偏见，使得领导的想法不一定正确，也不一定能够顺利实施。

就我个人的经历来说，领导要求我进行一次技术重构。由于我对这个项目还不够熟悉，所以我完全按照领导的方案去操作，没有怀疑过。事后回顾，发现这个方案过于繁重，其实只需要调整前端接口就能解决问题，但最终我们却对底层数据库存储、业务代码和接口交互方式进行了全面改变。

最终收益并不高，反而导致了一个严重的故障。既没有获得功劳，也没有得到应有的认可。

事后反思，我意识到我不应该盲目按照领导的方案去执行，而是应该怀着质疑和批判的态度去思考他的方案。多寻求几个备选方案，进行横向比较，找到成本最低、实施最简单的方案。

4.1 汇报材料高大上，实现方案短平快

私底下，可以对老板坦诚这件事，就是没什么搞头。但是对外文章要写得高大上！

技术方案要高大上，实现方案要短平快。

面对不确定的目标、面对不好完成的任务，要适当吹牛逼和画饼。汇报文档可以和实现方案有出入。

模糊的目标，往往难以执行和完成，技术方案越复杂，越容易出问题。本来就没什么收益，还引出一堆线上问题，只能当项目失败的背锅侠，得不偿失。

一定要想办法，把实现方案做的简单。这样有3个好处；

程序员一般情况下习惯于实话实说，如果说假话，一定是被人逼得。

不会写文档？# 写文档不用发愁，1000个互联网常用词汇送给你

不会写技术方案？# 不会画图? 17 张图教你写好技术方案！

5、申请专门的团队攻克难关！

例如重构系统涉及到上下游系统，一个人搞不定的！要向领导寻求帮助，让上下游同事一起干这件事。

让熟悉系统的人跟自己一起做，拉更多的人入伙！多个人一起承担重任！ 这种组织上的安排，只能由领导出面解决。

假如别的同事经常打扰你，总让你确认这件事，确认那件事，总让你帮忙梳理文档，你愿意配合吗？ 每个人都很忙，没人愿意长期给你干活。

让领导帮忙成立重构小组！然后你可以给每个人都分派任务，比自己独自硬扛，成功概率大很多。

虽然重构的目标不明确，但你可以尝试明确每个人的责任，设置短期的里程碑。例如前三天梳理整理资料，每天开早会， push大家干活。（这样很招人恨！没办法，领导卷的）

5.1 寻求合作的最大公约数

重大项目往往需要多个团队同时配合，即便你申请了专门的小组跟进这件事，但是别人可能出工不出力！

他们不配合的原因在于：不光没有收益，付出还很多。成本和收益不对等，人家不愿意很正常。保持平常心！不要带着脾气看待这件事！

略微想一下就明白，既然你觉得这件事风险高、收益低，难道其他人看不出来吗？

作为项目的负责人推动事情更加困难。当别人不配合时，除了把矛盾上升到上层领导外，还有哪些更好的办法呢？

总之，涉及多个团队合作时，除了依靠上层领导的强硬干预之外，还要想一些合作共赢的方案！

6、争取更多的资源支持

没有完不成的事情，只要资源充裕，任何事情都是有希望的。当你面临棘手的问题时，除了打起12分的精气神，还要多想想和领导申请资源啊！

最重要的包括人力资源、时间资源。如果空口白牙就要人，可能比较困难。

这需要你在调研阶段深入思考，预想到系统的挑战点，把任务细分，越细越好，然后拿着排期表找领导，要人、要时间。

如果人和时间都不给！可以多试几次，软磨硬泡也是好办法！

此外还有别的办法，例如 ”偷工减料"。你可以和领导沟通，方案中哪些内容不重要，是否可以砍掉。”既然你不给人，砍掉不重要的部分，减少工作量，总可以吧"

除此之外，还可以考虑分期做。信用卡可以分期付款，技术重构当然也可以分期优化！

7、能分期就分期

对于技术重构类工作，一定要想办法分期重构，不要一次性只求大而全！

分期的好处自不必说，在设计方案时一定要想如何分期完成。

如果对一个系统不熟悉，建议分期方案 先易后难！先做简单的，逐渐地你对系统会有更深入的理解！

如果对一个系统很熟悉，可以考虑先难后易。先把最困难的完成！后面会轻松很多！

但是我还是建议庞大的重构工作，先易后难！先做简单的，拖着拖着，也许就不需要重构了呢！

8、即便没有功劳但是要收获苦劳

当一件事干成很难的时候，要想办法把损失降到最低。一定要想着先保护自己！别逞能！

工作几年的朋友应该知道，不是所有的项目都能成功！甚至大部分项目在商业上是失败的！做不成一件事很正常！

如果一件事很难办成，功劳就不要想了。但是可以赚一份苦劳。

这要求你能把自己的困难说给领导，例如其他团队不配合！你可以一直和领导反馈，并寻求领导的帮助。

日常工作的内容也要有文档留存。工作以周报形式单独和领导汇报！要让领导知道你每周的进展，向领导传递一个事实：“每一周你都努力地在做事，并且也都及时汇报了，日后干不成，可别只怪我一人啊！”

接到一个烫手山芋，处理起来很难~ 斗智斗勇，所以能躲开还是躲开啊！

9、转变观念：放弃责任心，领导关注的内容重点完成

出于责任心的角度，我们可能认为领导提出的方案并不正确，甚至认为领导给自己派的工作完全没有意义。

你可能认为领导的Idea 不切合实际！

出于责任心，你有你的想法，你有你的原则！你认为系统这样重构更适合！但那又怎样，除非你有足够的理由说服领导，否则改变不了什么。

站在更高的位置能看的更远，一般领导都会争取团队利益最大化。虽然看起来不切实际，但是努力拼一拼，也许能给团队带来更大的利益。这可能是领导的想法！说白了，就是领导想让团队多去冲锋陷阵，多把一些不可能变成可能！

和领导保持节奏，领导更关注哪件事，就尽力把这件事做好！ 放弃自己所谓的“责任心”。

10、挑战、机遇、风险并存。

在互联网稳定期，各行各业都在内卷，公司内部更是在内卷！

在没有巨大增量的团队和公司里，靠内卷出成绩是很困难的事情。有时候真的很绝望，每一分钟都想躺平 。

像这种目标不明确、执行方案不明确、结果不明确、需要协调其他团队干活的难事越来越多！风险高、低收益的事情谁都不想干！

但是一旦能做成，对于个人也是极大地锻炼。所以大家不要一味地悲观，遇到这种棘手的事情，多和领导沟通，多想想更优的解决方案。也许能走出一条捷径，取得极大的成果~

0. 引言

es的java客户端不太友好的语法一直饱受诟病，书写一个查询语句可能需要书写一大串的代码，如果能像mybatis--plus一样，支持比较灵活方便的语句生成器那就好了。

于是为elasticsearch而生的ORM框架Easy-Es诞生了，使用及其方便快捷，今天我们就一起来学习easy-es，对比看看原生java-client方便之处在哪儿。

1. Easy-Es简介

Easy-Es是以elasticsearch官方提供的RestHighLevelClient为基础，而开发的一款针对es的ORM框架，类似于es版的mybatis-plus，可以让开发者无需掌握es复杂的DSL语句，只要会mysql语法即可使用es，快速实现es客户端语法

官方文档：http://www.easy-es.cn/

2. Easy-Es使用

1、引入依赖

<!-- 引入easy-es最新版本的依赖-->

        <dependency>

            <groupId>org.dromara.easy-es</groupId>

            <artifactId>easy-es-boot-starter</artifactId>

            <version>2.0.0-beta3</version>

        </dependency>



        <!-- 排除springboot中内置的es依赖,以防和easy-es中的依赖冲突-->

        <dependency>

            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter-web</artifactId>

            <exclusions>

                <exclusion>

                    <groupId>org.elasticsearch.client</groupId>

                    <artifactId>elasticsearch-rest-high-level-client</artifactId>

                </exclusion>

                <exclusion>

                    <groupId>org.elasticsearch</groupId>

                    <artifactId>elasticsearch</artifactId>

                </exclusion>

            </exclusions>

        </dependency>

        <dependency>

            <groupId>org.elasticsearch.client</groupId>

            <artifactId>elasticsearch-rest-high-level-client</artifactId>

            <version>7.14.0</version>

        </dependency>

        <dependency>

            <groupId>org.elasticsearch</groupId>

            <artifactId>elasticsearch</artifactId>

            <version>7.14.0</version>

        </dependency>

2、添加配置项，这里只配置了几个基本的配置项，更多配置可参考官网文档：easy-es 配置介绍

easy-es: 

  # es地址、账号密码

  address: 192.168.244.11:9200

  username: elastic

  password: elastic

3、在启动类中添加es mapper文件的扫描路径

@EsMapperScan("com.example.easyesdemo.mapper")

4、创建实体类，通过@IndexName注解申明索引名称及分片数， @IndexField注解申明字段名、数据类型、分词器等，更多介绍参考官方文档：essy-es 注解介绍

@IndexName(value = "user_easy_es")

@Data

public class UserEasyEs {



    @IndexId(type = IdType.CUSTOMIZE)

    private Long id;



    private String name;



    private Integer age;



    private Integer sex;



    @IndexField(fieldType = FieldType.TEXT, analyzer = Analyzer.IK_SMART, searchAnalyzer = Analyzer.IK_SMART)

    private String address;



    @IndexField(fieldType = FieldType.DATE, dateFormat = "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis")

    private Date createTime;



    private String createUser;



}

5、创建mapper类，继承BaseEsMapper类，注意这里的mapper一定要创建到第3步中设置的mapper扫描路径下com.example.easyesdemo.mapper

public interface UserEsMapper extends BaseEsMapper<UserEasyEs> {

}

6、创建controller，书写创建索引、新增、修改、查询的接口

@RestController

@RequestMapping("es")

@AllArgsConstructor

public class UserEsController {



    private final UserEsMapper userEsMapper;



    /**

     * 创建索引

     * @return

     */

    @GetMapping("create")

    public Boolean createIndex(){

        return userEsMapper.createIndex();

    }



    @GetMapping("save")

    public Integer save(Long id){

        UserEasyEs user = new UserEasyEs();

        user.setId(id);

        user.setName("用户"+id);

        user.setAddress("江苏省无锡市滨湖区");

        user.setAge(30);

        user.setSex(1);

        user.setCreateUser("admin");

        user.setCreateTime(new Date());

        Long count = userEsMapper.selectCount(EsWrappers.lambdaQuery(UserEasyEs.class).eq(UserEasyEs::getId, id));

        if(count > 0){

            return userEsMapper.updateById(user);

        }else{

            return userEsMapper.insert(user);

        }

    }



    @GetMapping("search")

    public List<UserEasyEs> search(String name, String address){

        List<UserEasyEs> userEasyEs = userEsMapper.selectList(

                EsWrappers.lambdaQuery(UserEasyEs.class)

                        .eq(UserEasyEs::getName, name)

                        .match(UserEasyEs::getAddress, address)

                );

        return userEasyEs;

    }



}

7、分别调用几个接口

• 创建索引
  
  kibana中查询索引，发现创建成功
  


• 新增接口
  这里新增了4笔
  
  数据新增成功
  


• 数据查询

如上便是针对easy-es的简单使用，这里的用法都与mp类似，上手相当简单，不用再写那些复杂的DSL语句了

3. 拓展介绍

• 条件构造器

上述演示，我们构造查询条件时，使用了EsWrappers来构造条件，用法与mp及其类型，大家根据提示就可以推导出方法如何书写，更详细的使用说明可以查看官方文档：easy-es 条件构造器介绍

• 索引托管

如果想要自动根据创建的es实体类来创建对应的索引，那么只需要调整索引的托管模式为非手动模式即可，因为这里我不需要自动同步数据，所以选择非平滑模式

easy-es:

  global-config:

    process_index_mode: not_smoothly

其中三种模式的区别为：
平滑模式：smoothly，索引的创建、数据更新迁移等都由easy-es自动完成
非平滑模式：not_smoothly，索引自动创建，但不会自动迁移数据
手动模式：manual，全部操作由用户手动完成，默认模式

• 数据同步

如果数据源是来自mysql, 那么建议使用canal来进行同步，canal的使用可在我主页搜索。
其次还有DataX, Logstash等同步工具，当然你也可以使用easy-es提供的CRUD接口，来手动同步数据

• 日志打印

通过开启日志，可以在控制台打印执行的DSL语句，更加方便我们在开发阶段进行问题排查

logging:

  level:

   tracer: trace # 开启trace级别日志,在开发时可以开启此配置,则控制台可以打印es全部请求信息及DSL语句,为了避免重复,开启此项配置后,可以将EE的print-dsl设置为false.

• 聚合查询
  easy-es实现的聚合查询，只要是针对gr0up by这类聚合，也就是es中的Terms aggregation，以及最大值、最小值、平均值、求和，而对于其他类型的聚合，还在不断更新中，但这里大家也需要了解，es的聚合和mysql的聚合完全是不一样的维度和复杂度，es支持非常多的聚合查询，所以其他类型的实现还需要借助RestHighLevelClient来实现

我们利用easy-es来实现下之前书写的聚合案例

@RestController

@AllArgsConstructor

@RequestMapping("order")

public class OrderEsController {



    private final OrderTestEsMapper orderEsMapper;



    @GetMapping("search")

    public String search(){

        SearchResponse search = orderEsMapper.search(EsWrappers.lambdaQuery(OrderTest.class).groupBy(OrderTest::getStatus));



        // 包装查询结果

        Aggregations aggregations = search.getAggregations();

        Terms terms = (Terms)aggregations.asList().get(0);

        List<? extends Terms.Bucket> buckets = terms.getBuckets();

        HashMap<String,Long> statusRes = new HashMap<>();

        buckets.forEach(bucket -> {

            statusRes.put(bucket.getKeyAsString(),bucket.getDocCount());

        });

        System.out.println("---聚合结果---");

        System.out.println(statusRes);

        return statusRes.toString();

    }

}

可以看到实际上的查询语句就一行，而其他的都是对返回结果的封装，因为es本身返回的数据是封装到嵌套的对象中的，所以我们需要对其进行包装

对比原始的查询语句，其易用性上的提升还是很明显的

4. 总结

至此对easy-es的介绍就结束了，可以看到如果是针对es实现CRUD上，easy-es表现出非常好的便捷性，而在复杂的聚合查询中，仍然还有进步空间，目前还需要借助RestHighLevelClient，但easy-es的出现，为未来提供更好用的ES ORM框架，提供了希望和方向

文中演示代码见：gitee.com/wuhanxue/wu…

背景 (书接上回)

• ui妹子的无理要求，我通通满足了。但是不出意外的话，意外就出来了。


• 此功能在上线之后，我们的业务在客户app内使用刷脸的时候会因为内存过高导致app将webview杀死。


• 然后我们leader爆了，让我排查问题。可是可是，我哪里会排查内存泄漏呀。


• 我：我不会。你自己不会上吗？你tm天天端个茶，抽个烟，翘个二郎腿，色眯眯的看着ui妹妹。


• 领导：污蔑，你纯粹就是污蔑。我tm现在就可以让你滚蛋，你信吗？


• 我：我怕你个鸟哦，我还不知道你啥水平，你tm能写出来个防抖节流，我就给你磕头。


• 领导：hi～ui妹妹，今天过的好吗，来，哥哥这里有茶喝。（此时ui妹妹路过）。你赶快给我干活，以后ui妹妹留给你。


• 艹！你早这么说不就好了。

开始学习

Chrome devTools查看内存情况

• 打开Chrome的无痕模式，这样做的目的是为了屏蔽掉Chrome插件对我们之后测试内存占用情况的影响


• 打开开发者工具，找到Performance这一栏，可以看到其内部带着一些功能按钮，例如：开始录制按钮；刷新页面按钮；清空记录按钮；记录并可视化js内存、节点、事件监听器按钮；触发垃圾回收机制按钮等

简单录制一下百度页面，看看我们能获得什么，如下动图所示：

从上图中我们可以看到，在页面从零到加载完成这个过程中JS Heap（js堆内存）、documents（文档）、Nodes（DOM节点）、Listeners（监听器）、GPU memory（GPU内存）的最低值、最高值以及随时间的走势曲线，这也是我们主要关注的点

看看开发者工具中的Memory一栏，其主要是用于记录页面堆内存的具体情况以及js堆内存随加载时间线动态的分配情况

堆快照就像照相机一样，能记录你当前页面的堆内存情况，每快照一次就会产生一条快照记录

如上图所示，刚开始执行了一次快照，记录了当时堆内存空间占用为33.7MB，然后我们点击了页面中某些按钮，又执行一次快照，记录了当时堆内存空间占用为32.5MB。并且点击对应的快照记录，能看到当时所有内存中的变量情况（结构、占总占用内存的百分比...）

在开始记录后，我们可以看到图中右上角有起伏的蓝色与灰色的柱形图，其中蓝色表示当前时间线下占用着的内存；灰色表示之前占用的内存空间已被清除释放

在得知有内存泄漏的情况存在时，我们可以改用Memory来更明确得确认问题和定位问题

首先可以用Allocation instrumentation on timeline来确认问题，如下图所示：

内存泄漏的场景

• 闭包使用不当引起内存泄漏


• 全局变量


• 分离的DOM节点


• 控制台的打印


• 遗忘的定时器

1. 闭包使用不当引起内存泄漏

使用Performance和Memory来查看一下闭包导致的内存泄漏问题

<button onclick="myClick()">执行fn1函数button>

<script>

    function fn1 () {

        let a = new Array(10000)  // 这里设置了一个很大的数组对象



        let b = 3



        function fn2() {

            let c = [1, 2, 3]

        }



        fn2()



        return a

    }



    let res = []  



    function myClick() {

        res.push(fn1())

    }

script>

在退出fn1函数执行上下文后，该上下文中的变量a本应被当作垃圾数据给回收掉，但因fn1函数最终将变量a返回并赋值给全局变量res，其产生了对变量a的引用，所以变量a被标记为活动变量并一直占用着相应的内存，假设变量res后续用不到，这就算是一种闭包使用不当的例子

设置了一个按钮，每次执行就会将fn1函数的返回值添加到全局数组变量res中，是为了能在performacne的曲线图中看出效果，如图所示：

• 在每次录制开始时手动触发一次垃圾回收机制，这是为了确认一个初始的堆内存基准线，便于后面的对比，然后我们点击了几次按钮，即往全局数组变量res中添加了几个比较大的数组对象，最后再触发一次垃圾回收，发现录制结果的JS Heap曲线刚开始成阶梯式上升的，最后的曲线的高度比基准线要高，说明可能是存在内存泄漏的问题


• 在得知有内存泄漏的情况存在时，我们可以改用Memory来更明确得确认问题和定位问题


• 首先可以用Allocation instrumentation on timeline来确认问题，如下图所示：

• 在我们每次点击按钮后，动态内存分配情况图上都会出现一个蓝色的柱形，并且在我们触发垃圾回收后，蓝色柱形都没变成灰色柱形，即之前分配的内存并未被清除


• 所以此时我们就可以更明确得确认内存泄漏的问题是存在的了，接下来就精准定位问题，可以利用Heap snapshot来定位问题，如图所示：

• 第一次先点击快照记录初始的内存情况，然后我们多次点击按钮后再次点击快照，记录此时的内存情况，发现从原来的1.1M内存空间变成了1.4M内存空间，然后我们选中第二条快照记录，可以看到右上角有个All objects的字段，其表示展示的是当前选中的快照记录所有对象的分配情况，而我们想要知道的是第二条快照与第一条快照的区别在哪，所以选择Object allocated between Snapshot1 and Snapshot2即展示第一条快照和第二条快照存在差异的内存对象分配情况，此时可以看到Array的百分比很高，初步可以判断是该变量存在问题，点击查看详情后就能查看到该变量对应的具体数据了

以上就是一个判断闭包带来内存泄漏问题并简单定位的方法了

2. 全局变量

全局的变量一般是不会被垃圾回收掉的当然这并不是说变量都不能存在全局，只是有时候会因为疏忽而导致某些变量流失到全局，例如未声明变量，却直接对某变量进行赋值，就会导致该变量在全局创建，如下所示：

function fn1() {

    // 此处变量name未被声明

    name = new Array(99999999)

}



fn1()

• 此时这种情况就会在全局自动创建一个变量name，并将一个很大的数组赋值给name，又因为是全局变量，所以该内存空间就一直不会被释放


• 解决办法的话，自己平时要多加注意，不要在变量未声明前赋值，或者也可以开启严格模式，这样就会在不知情犯错时，收到报错警告，例如

function fn1() {

    'use strict';

    name = new Array(99999999)

}



fn1()

3. 分离的DOM节点

假设你手动移除了某个dom节点，本应释放该dom节点所占用的内存，但却因为疏忽导致某处代码仍对该被移除节点有引用，最终导致该节点所占内存无法被释放，例如这种情况

<div id="root">

    <div class="child">我是子元素div>

    <button>移除button>

div>

<script>

  let btn = document.querySelector('button')

  let child = document.querySelector('.child')

  let root = document.querySelector('#root')

  

  btn.addEventListener('click', function() {

      root.removeChild(child)

  })

script>

该代码所做的操作就是点击按钮后移除.child的节点，虽然点击后，该节点确实从dom被移除了，但全局变量child仍对该节点有引用，所以导致该节点的内存一直无法被释放，可以尝试用Memory的快照功能来检测一下，如图所示

同样的先记录一下初始状态的快照，然后点击移除按钮后，再点击一次快照，此时内存大小我们看不出什么变化，因为移除的节点占用的内存实在太小了可以忽略不计，但我们可以点击第二条快照记录，在筛选框里输入detached，于是就会展示所有脱离了却又未被清除的节点对象

解决办法如下图所示：

<div id="root">

    <div class="child">我是子元素div>

    <button>移除button>

div>

<script>

    let btn = document.querySelector('button')



    btn.addEventListener('click', function() {  

        let child = document.querySelector('.child')

        let root = document.querySelector('#root')



        root.removeChild(child)

    })



script>

改动很简单，就是将对.child节点的引用移动到了click事件的回调函数中，那么当移除节点并退出回调函数的执行上文后就会自动清除对该节点的引用，那么自然就不会存在内存泄漏的情况了，我们来验证一下，如下图所示：

结果很明显，这样处理过后就不存在内存泄漏的情况了

4. 控制台的打印

<button>按钮button>

<script>

    document.querySelector('button').addEventListener('click', function() {

        let obj = new Array(1000000)



        console.log(obj);

    })

script>

我们在按钮的点击回调事件中创建了一个很大的数组对象并打印，用performance来验证一下

开始录制，先触发一次垃圾回收清除初始的内存，然后点击三次按钮，即执行了三次点击事件，最后再触发一次垃圾回收。查看录制结果发现JS Heap曲线成阶梯上升，并且最终保持的高度比初始基准线高很多，这说明每次执行点击事件创建的很大的数组对象obj都因为console.log被浏览器保存了下来并且无法被回收

接下来注释掉console.log，再来看一下结果：

<button>按钮button>

<script>

    document.querySelector('button').addEventListener('click', function() {

        let obj = new Array(1000000)



        // console.log(obj);

    })

script>

可以看到没有打印以后，每次创建的obj都立马被销毁了，并且最终触发垃圾回收机制后跟初始的基准线同样高，说明已经不存在内存泄漏的现象了

其实同理 console.log也可以用Memory来进一步验证

未注释 console.log

注释掉了console.log

最后简单总结一下：在开发环境下，可以使用控制台打印便于调试，但是在生产环境下，尽可能得不要在控制台打印数据。所以我们经常会在代码中看到类似如下的操作：

// 如果在开发环境下，打印变量obj

if(isDev) {

    console.log(obj)

}

这样就避免了生产环境下无用的变量打印占用一定的内存空间，同样的除了console.log之外，console.error、console.info、console.dir等等都不要在生产环境下使用

5. 遗忘的定时器

定时器也是平时很多人会忽略的一个问题，比如定义了定时器后就再也不去考虑清除定时器了，这样其实也会造成一定的内存泄漏。来看一个代码示例：

<button>开启定时器button>

<script>



    function fn1() {

        let largeObj = new Array(100000)



        setInterval(() => {

            let myObj = largeObj

        }, 1000)

    }



    document.querySelector('button').addEventListener('click', function() {

        fn1()

    })

script>

这段代码是在点击按钮后执行fn1函数，fn1函数内创建了一个很大的数组对象largeObj，同时创建了一个setInterval定时器，定时器的回调函数只是简单的引用了一下变量largeObj，我们来看看其整体的内存分配情况吧：

按道理来说点击按钮执行fn1函数后会退出该函数的执行上下文，紧跟着函数体内的局部变量应该被清除，但图中performance的录制结果显示似乎是存在内存泄漏问题的，即最终曲线高度比基准线高度要高，那么再用Memory来确认一次：

• 在我们点击按钮后，从动态内存分配的图上看到出现一个蓝色柱形，说明浏览器为变量largeObj分配了一段内存，但是之后这段内存并没有被释放掉，说明的确存在内存泄漏的问题，原因其实就是因为setInterval的回调函数内对变量largeObj有一个引用关系，而定时器一直未被清除，所以变量largeObj的内存也自然不会被释放


• 那么我们如何来解决这个问题呢，假设我们只需要让定时器执行三次就可以了，那么我们可以改动一下代码：

<button>开启定时器button>

<script>

    function fn1() {

        let largeObj = new Array(100000)

        let index = 0



        let timer = setInterval(() => {

            if(index === 3) clearInterval(timer);

            let myObj = largeObj

            index ++

        }, 1000)

    }



    document.querySelector('button').addEventListener('click', function() {

        fn1()

    })

script>

现在我们再通过performance和memory来看看还不会存在内存泄漏的问题

• performance

这次的录制结果就能看出，最后的曲线高度和初始基准线的高度一样，说明并没有内存泄漏的情况

• memory

这里做一个解释，图中刚开始出现的蓝色柱形是因为我在录制后刷新了页面，可以忽略；然后我们点击了按钮，看到又出现了一个蓝色柱形，此时就是为fn1函数中的变量largeObj分配了内存，3s后该内存又被释放了，即变成了灰色柱形。所以我们可以得出结论，这段代码不存在内存泄漏的问题

简单总结一下： 大家在平时用到了定时器，如果在用不到定时器后一定要清除掉，否则就会出现本例中的情况。除了setTimeout和setInterval，其实浏览器还提供了一个API也可能就存在这样的问题，那就是requestAnimationFrame

• 好了好了，学完了，ui妹妹我来了

• ui妹妹：去你m的，滚远点

好了兄弟们，内存泄漏学会了吗？

最近两周，总有大三或研二的同学在微信上跟我说：

“学长，我想在明年上半年的时候找个中大厂的实习，以及在秋招的时候拿个好点儿的offer。

但我现在没有项目经验，八股文才刚刚开始看，算法只会刷几十道简单和中等难度的，现在时间一天天过去，我自己并不在学习状态，感觉非常焦虑，甚至焦虑得晚上睡不着觉。”

其实，我非常理解同学们有这种焦虑状态，而形成这种状态的原因，我的分析如下。

恐惧来源于未知，而焦虑来自于不可控，大部分又焦虑又没有学习状态的同学，往往都有类似困惑：

而正是这种努力了也不一定更好，自己的命运无法掌控的感觉，让他们产生了不安全感和焦虑。

恰恰，大部分处于这种状态的同学，都是学习成绩和技术能力处于中等水平的。

因为按照现在这市场行情，学习成绩和技术能力处于下游的同学，早就已经放飞自我、彻底躺平了。

他们的想法是：毕业后的工作爱找成啥样就找成啥样呗，反正最后有个工作干着就行。现在这经济环境，就算努力了也大概率没什么好的结果，反而希望越大，失望就越大，再给自己累出一身病来，得不偿失。

而在各方面都比较优秀的同学，感到焦虑的人也不是很多，毕竟那份骨子里的自信和从容还是有的。

下面，我就给这类焦虑的同学支支招，用我自己思考的“双标一力”策略来化解这种负面情绪。

“双标一力”，即：制定目标 + 拆解目标 + 执行力。

制定目标

有句话是这样说的，梦想还是要有的，万一实现了呢？

但如果真的把不切实际的梦想作为目标，容易让自己整体的执行落地计划和动作变形，导致自己越来越焦虑，最终彻底摆烂。

BTW：这里所说的目标，是以校招生的身份，拿到心仪公司的offer。

举个例子，如果你是双非二本学历，技术能力也没牛逼到傲视群雄的地步，我不建议你把目标定为互联网大厂。

你可以把目标更切实际地定为，找个福利待遇中上等的公司，保证先上牌桌，再图发展。

如果你不知道如何给自己制定目标，我建议你采用“参照对标”的方式。

比如：你目前的学习成绩和技术储备在学校中排名前 30%的话，可以把去年前20%的学长学姐所去的公司作为目标。毕竟，去年和今年的招聘市场环境相差不大。

为什么今年前30%对去年的前20%呢？很简单，就是留一些空间让你去追赶的。

拆解目标

制定完目标后，你的焦虑感依然是存在的，还是觉得心里没底。

接下来就要看，你想要拿到目标公司的offer，都需要做哪些技术储备，以及需要储备到什么程度了。

举个例子，现在你想拿到互联网大厂的Java后端岗的offer，那以下几个方面的储备是缺一不可的。其中包括：

下面我们继续对其进行拆解，以此得出不同时间节点需要做完哪些事情。

我们按照秋招九月份开始，那如果具备上述至少3个月的大厂实习经历的话，那意味着最迟六月初就要去大厂开始实习了。

我们继续往前推算，如果6月份入职实习，那预留一个半月找实习的时间，是比较充裕的，也就是4月中旬。

接下来，我们再看项目、八股文和算法应该如何进行安排。

其中，项目和八股文是有先后顺序的，如果你在没练手过任何项目的情况下，直接去背八股文，那这个过程会非常痛苦。

但反过来，你没有储备任何八股文，但只要掌握Java基本语法和SpringBoot、MyBatis的用法，跟着黑马、尚硅谷、慕课的视频敲两个新手小白项目，那应该是不难的。

而刷算法这件事情，只要你大学期间有些数据结构和算法的底子，那直接开始即可。另外，算法储备会比较耗时，所以越早开始越好。

那整体的拆解路径也就出来了，我们假设从2023年的12月中旬开始，进行如下安排：

执行力

这点没什么好说的，干就完了。真正的聪明人，都喜欢心无旁骛地下笨功夫。

我相信，只要你能用心坚持一个月，看着自己之前的学习计划正在如期逐步落地，你的焦虑感就会变为成就感。

结语

希望我写的这些，能够对正在焦虑中的大三、研二的计算机专业同学有所帮助。

一、动态rem适配方案：适合H5项目的适配方案

1. @media媒体查询适配

首先，我们需要设置一个根元素的基准值，这个基准值通常根据视口宽度进行计算。可以在项目的 CSS 文件中，通过媒体查询动态调整根元素的 font-size。

html {

  font-size: 16px; /* 默认基准值 */

}

...

@media (min-width: 1024px) {

  html {

    font-size: 14px; /* 适配较大屏幕 */

  }

}

@media (min-width: 1440px) {

  html {

    font-size: 16px; /* 适配超大屏幕 */

  }

}

2. PostCSS 插件（自动转换）实现 px2rem

手动转换 px 为 rem 可能很繁琐，因此可以使用 PostCSS 插件 postcss-pxtorem 来自动完成这一转换。

2.1 安装 postcss-pxtorem

首先，在项目中安装 postcss-pxtorem 插件：

npm install postcss-pxtorem --save-dev

2.2 配置 PostCSS

然后，在项目根目录创建或编辑 postcss.config.js 文件，添加 postcss-pxtorem 插件配置：

/* postcss.config.cjs  */

module.exports = {

  plugins: {

    'postcss-pxtorem': {

      rootValue: 16, // 基准值，对应于根元素的 font-size

      unitPrecision: 5, // 保留小数点位数

      propList: ['*', '!min-width', '!max-width'], // 排除 min-width 和 max-width 属性

      selectorBlackList: [], // 忽略的选择器

      replace: true, // 替换而不是添加备用属性

      mediaQuery: false, // 允许在媒体查询中转换 px

      minPixelValue: 0 // 最小的转换数值

    }

  }

};

/* vite  */

export default defineConfig({

  css: {

    postcss: './postcss.config.cjs',

  }

})

3. 在 CSS/SCSS 中使用 px

在编写样式时，依然可以使用 px 进行布局：

.container {

  width: 320px;

  padding: 16px;

}



.header {

  height: 64px;

  margin-bottom: 24px;

}

4. 构建项目

通过构建工具（如 webpack/vite ）运行项目时，PostCSS 插件会自动将 px 转换为 rem。

5. 可以不用@media媒体查询，动态动态调整font-size

为了实现更动态的适配，可以通过 JavaScript 动态设置根元素的 font-size：

/**utils/setRootFontSize**/

function setRootFontSize(): void {

     const docEl = document.documentElement;

     const clientWidth = docEl.clientWidth;

     if (!clientWidth) return;

     const baseFontSize = 16; // 基准字体大小

     const designWidth = 1920; // 设计稿宽度

     docEl.style.fontSize = (baseFontSize * (clientWidth / designWidth)) + 'px';

   }

   export default setRootFontSize;



/**utils/setRootFontSize**/

/**APP**/

import setRootFontSize from '../utils/setRootFontSize';

import { useEffect } from 'react';



export default function App() {

  useEffect(() => {

    // 设置根元素的字体大小

    setRootFontSize();

    // 窗口大小改变时重新设置

    window.addEventListener('resize', setRootFontSize);

    // 清除事件监听器

    return () => {

      window.removeEventListener('resize', setRootFontSize);

    };

  }, []);

  

  return (

    <>

      <div>

        <MyRoutes />

      </div>

    </>

  )

}

/**APP**/

这样，无论视口宽度如何变化，页面元素都会根据基准值动态调整大小，确保良好的适配效果。
通过上述步骤，可以实现布局使用 px，并动态转换为 rem 的适配方案。这个方案不仅使得样式编写更加简洁，还提高了适配的灵活性。

注：如果你使用了 setRootFontSize 动态调整根元素的 font-size，就不再需要使用 @media 查询来调整根元素的字体大小了。这是因为 setRootFontSize 函数已经根据视口宽度动态调整了 font-size，从而实现了自适应。

这种方式简化了响应式设计，使得样式统一管理更加简单，同时保留了灵活性和适应性。

6. 效果对比（非H5界面）

图一为界面px 适配，效果为图片，文字等大小固定不变。

图二为动态rem适配：整体随界面扩大而扩大，能够保持相对比例。

7. Tips

• 动态rem此方案比较适合H5屏幕适配


• 注意: PostCSS 转换rem应排除 min-width 、max-width、min-height和max-height ，以免影响整体界面

二、其他适配

1. 弹性盒模型（Flexbox）

Flexbox 是一种布局模型，能够轻松地实现响应式布局。它允许元素根据容器的大小自动调整位置和大小。

.container {

  display: flex;

  flex-wrap: wrap;

}



.item {

  flex: 1 1 100%; /* 默认情况下每个元素占满一行 */

}



@media (min-width: 600px) {

  .item {

    flex: 1 1 50%; /* 在较宽的屏幕上，每个元素占半行 */

  }

}



@media (min-width: 1024px) {

  .item {

    flex: 1 1 33.33%; /* 在更宽的屏幕上，每个元素占三分之一行 */

  }

}

2. 栅格系统（Grid System）

栅格系统是一种常见的响应式布局方案，广泛应用于各种框架（如 Bootstrap）。通过定义行和列，可以轻松地创建复杂的布局。

.container {

  display: grid;

  grid-template-columns: 1fr; /* 默认情况下每行一个列 */

  gap: 10px;

}



@media (min-width: 600px) {

  .container {

    grid-template-columns: 1fr 1fr; /* 在较宽的屏幕上，每行两个列 */

  }

}



@media (min-width: 1024px) {

  .container {

    grid-template-columns: 1fr 1fr 1fr; /* 在更宽的屏幕上，每行三个列 */

  }

}

3. 百分比和视口单位

使用百分比（%）、视口宽度（vw）、视口高度（vh）等单位，可以根据视口尺寸调整元素大小。

  /* 示例：百分比和视口单位 */

  .container {

    width: 100%;

    height: 50vh; /* 高度为视口高度的一半 */

}



.element {

  width: 50%; /* 宽度为容器的一半 */

  height: 10vw; /* 高度为视口宽度的 10% */

}

4. 响应式图片

根据设备分辨率和尺寸加载不同版本的图片，以提高性能和视觉效果。可以使用 srcset 和 sizes 属性。

  <!-- 示例：响应式图片 -->

  <img 

    src="small.jpg" 

    srcset="medium.jpg 600w, large.jpg 1024w" 

    sizes="(max-width: 600px) 100vw, (max-width: 1024px) 50vw, 33.33vw" 

    alt="Responsive Image">

5. CSS Custom Properties（CSS变量）

使用 CSS 变量可以更灵活地定义和调整样式，同时通过 JavaScript 动态改变变量值实现响应式设计。

:root {

  --main-padding: 20px;

}



.container {

  padding: var(--main-padding);

}



@media (min-width: 600px) {

:root {

    --main-padding: 40px;

  }

}

前言

闲来无事，利用摸鱼时间实现实时天气的小功能

目录

效果图

这里样式我就不做处理了，地图可以不用做展示，只需要拿到获取到天气的结果，结合自己的样式展示就可以了，未来天气可以结合echarts进行展示，页面效果更佳

实现

这里应用名称可以随便取（个人建议功能名称或者项目称）

3.获取 key 和密钥

4.获取当前城市定位

首先，先安装依赖

npm install @amap/amap-jsapi-loader --save

或者

pnpm add @amap/amap-jsapi-loader --save

页面使用时引入即可 import AMapLoader from "@amap/amap-jsapi-loader"

/**在index.html引入密钥,不添加会导致某些API调用不成功*/



<script type="text/javascript">window._AMapSecurityConfig = 

{securityJsCode: "安全密钥"}</script>

  /** 1.  调用AMapLoader.load方法，通过传入一个对象作为参数来指定加载地图时的配置信息。

   *  -   key: 申请好的Web端开发者Key，是必填项，用于授权您的应用程序使用高德地图API。

   *  -   version: 指定要加载的JSAPI版本，不指定时默认为1.4.15。

   *  -   plugins: 需要使用的插件列表，如比例尺、缩放控件等。

   */

  function initMap() {

  AMapLoader.load({

    key: "申请好的Web端开发者Key", // 申请好的Web端开发者Key，首次调用 load 时必填

    version: "2.0", // 指定要加载的 JSAPI 的版本，缺省时默认为 1.4.15

    plugins: [

      "AMap.ToolBar",

      "AMap.Scale",

      "AMap.HawkEye",

      "AMap.MapType",

      "AMap.Geolocation",

      "AMap.Geocoder",

      "AMap.Weather",

      "AMap.CitySearch",

      "AMap.InfoWindow",

      "AMap.Marker",

      "AMap.Pixel",

    ], // 需要使用的的插件列表，如比例尺'AMap.Scale'等

  })

    .then((AMap) => {

      map.value = new AMap.Map("container", {

        //设置地图容器id

        resizeEnable: true,

        viewMode: "3D", //是否为3D地图模式

        zoom: 10, //初始化地图级别

        center: locationArr.value, //初始化地图中心点位置

      });



      getGeolocation(AMap);

      getCitySearch(AMap, map.value);

    })

    .catch((e) => {

      console.log(e);

    });

}



// 浏览器定位

const getGeolocation = (AMap: any) => {

  const geolocation = new AMap.Geolocation({

    enableHighAccuracy: true, //是否使用高精度定位，默认:true

    timeout: 1000, //超过10秒后停止定位，默认：5s

    position: "RB", //定位按钮的停靠位置

    offset: [10, 20], //定位按钮与设置的停靠位置的偏移量，默认：[10, 20]

    zoomToAccuracy: true, //定位成功后是否自动调整地图视野到定位点

  });

  map.value.addControl(geolocation);

  geolocation.getCurrentPosition(function (status: string, result: any) {

    if (status == "complete") {

      onComplete(result);

    } else {

      onError(result);

    }

  });

};



// IP定位获取当前城市信息

const getCitySearch = (AMap: any, map: any) => {

  const citySearch = new AMap.CitySearch();

  citySearch.getLocalCity(function (

    status: string,

    result: {

      city: string;

      info: string;

    }

  ) {

    if (status === "complete" && result.info === "OK") {

      console.log(

        "🚀 ~ file: map-container.vue:88 ~ getCitySearch ~ result:",

        result

      );

      // 查询成功，result即为当前所在城市信息

      getWeather(AMap, map, result.city);

    }

  });

};





onMounted(() => {

  initMap();

});

5.通过定位获取城市名称、区域编码，查询目标城市/区域的实时天气状况

const getWeather = (AMap: any, map: any, city: string) => {

  const weather = new AMap.Weather();

  weather.getLive(

    city,

    function (

      err: any,

      data: {

        city: string;

        weather: string;

        temperature: string;

        windDirection: string;

        windPower: string;

        humidity: string;

        reportTime: string;

      }

    ) {

      if (!err) {

        const str = [];

        str.push("<h4 >实时天气" + "</h4><hr>");

        str.push("<p>城市/区：" + data.city + "</p>");

        str.push("<p>天气：" + data.weather + "</p>");

        str.push("<p>温度：" + data.temperature + "℃</p>");

        str.push("<p>风向：" + data.windDirection + "</p>");

        str.push("<p>风力：" + data.windPower + " 级</p>");

        str.push("<p>空气湿度：" + data.humidity + "</p>");

        str.push("<p>发布时间：" + data.reportTime + "</p>");

        const marker = new AMap.Marker({

          map: map,

          position: map.getCenter(),

        });

        const infoWin = new AMap.InfoWindow({

          content:

            '<div class="info" style="position:inherit;margin-bottom:0;background:#ffffff90;padding:10px">' +

            str.join("") +

            '</div><div class="sharp"></div>',

          isCustom: true,

          offset: new AMap.Pixel(0, -37),

        });

        infoWin.open(map, marker.getPosition());

        marker.on("mouseover", function () {

          infoWin.open(map, marker.getPosition());

        });

      }

    }

  );

 }

完整代码

 <template>

  <div id="container"></div>

</template>



<script setup lang="ts">

import AMapLoader from "@amap/amap-jsapi-loader";

import { ref, onMounted, watch, reactive } from "vue";

const props = defineProps({

  search: {

    type: String,

    default: "杭州市",

  },

});



const isFalse = ref(false);



const map = ref<any>(null);

let locationArr = ref<any>();

watch(

  () => props.search,

  (newValue) => {

    console.log("search", newValue);

    initMap();

  }

);

function initMap() {

  AMapLoader.load({

    key: "申请好的Web端开发者Key", // 申请好的Web端开发者Key，首次调用 load 时必填

    version: "2.0", // 指定要加载的 JSAPI 的版本，缺省时默认为 1.4.15

    plugins: [

      "AMap.ToolBar",

      "AMap.Scale",

      "AMap.HawkEye",

      "AMap.MapType",

      "AMap.Geolocation",

      "AMap.Geocoder",

      "AMap.Weather",

      "AMap.CitySearch",

      "AMap.InfoWindow",

      "AMap.Marker",

      "AMap.Pixel",

    ], // 需要使用的的插件列表，如比例尺'AMap.Scale'等

  })

    .then((AMap) => {

      map.value = new AMap.Map("container", {

        //设置地图容器id

        resizeEnable: true,

        viewMode: "3D", //是否为3D地图模式

        zoom: 10, //初始化地图级别

        center: locationArr.value, //初始化地图中心点位置

      });



      getGeolocation(AMap);

      getCitySearch(AMap, map.value);

    })

    .catch((e) => {

      console.log(e);

    });

}



// 浏览器定位

const getGeolocation = (AMap: any) => {

  const geolocation = new AMap.Geolocation({

    enableHighAccuracy: true, //是否使用高精度定位，默认:true

    timeout: 1000, //超过10秒后停止定位，默认：5s

    position: "RB", //定位按钮的停靠位置

    offset: [10, 20], //定位按钮与设置的停靠位置的偏移量，默认：[10, 20]

    zoomToAccuracy: true, //定位成功后是否自动调整地图视野到定位点

  });

  map.value.addControl(geolocation);

  geolocation.getCurrentPosition(function (status: string, result: any) {

    if (status == "complete") {

      onComplete(result);

    } else {

      onError(result);

    }

  });

};



// IP定位获取当前城市信息

const getCitySearch = (AMap: any, map: any) => {

  const citySearch = new AMap.CitySearch();

  citySearch.getLocalCity(function (

    status: string,

    result: {

      city: string;

      info: string;

    }

  ) {

    if (status === "complete" && result.info === "OK") {

      console.log(

        "🚀 ~ file: map-container.vue:88 ~ getCitySearch ~ result:",

        result

      );

      // 查询成功，result即为当前所在城市信息

      getWeather(AMap, map, result.city);

    }

  });

};



// 天气

const getWeather = (AMap: any, map: any, city: string) => {

  const weather = new AMap.Weather();

  weather.getLive(

    city,

    function (

      err: any,

      data: {

        city: string;

        weather: string;

        temperature: string;

        windDirection: string;

        windPower: string;

        humidity: string;

        reportTime: string;

      }

    ) {

      console.log("🚀 ~ file: map-container.vue:96 ~ .then ~ data:", data);

      if (!err) {

        const str = [];

        str.push("<h4 >实时天气" + "</h4><hr>");

        str.push("<p>城市/区：" + data.city + "</p>");

        str.push("<p>天气：" + data.weather + "</p>");

        str.push("<p>温度：" + data.temperature + "℃</p>");

        str.push("<p>风向：" + data.windDirection + "</p>");

        str.push("<p>风力：" + data.windPower + " 级</p>");

        str.push("<p>空气湿度：" + data.humidity + "</p>");

        str.push("<p>发布时间：" + data.reportTime + "</p>");

        const marker = new AMap.Marker({

          map: map,

          position: map.getCenter(),

        });

        const infoWin = new AMap.InfoWindow({

          content:

            '<div class="info" style="position:inherit;margin-bottom:0;background:#ffffff90;padding:10px">' +

            str.join("") +

            '</div><div class="sharp"></div>',

          isCustom: true,

          offset: new AMap.Pixel(0, -37),

        });

        infoWin.open(map, marker.getPosition());

        marker.on("mouseover", function () {

          infoWin.open(map, marker.getPosition());

        });

      }

    }

  );



  // 未来4天天气预报

  weather.getForecast(

    city,

    function (err: any, data: { forecasts: string | any[] }) {

      console.log(

        "🚀 ~ file: map-container.vue:186 ~ getWeather ~ data:",

        data

      );



      if (err) {

        return;

      }

      var strs = [];

      for (var i = 0, dayWeather; i < data.forecasts.length; i++) {

        dayWeather = data.forecasts[i];

        strs.push(

          `<p>${dayWeather.date}&nbsp&nbsp${dayWeather.dayWeather}&nbsp&nbsp${dayWeather.nightTemp}~${dayWeather.dayTemp}℃</p><br />`

        );

      }

    }

  );

};



function onComplete(data: any) {

  console.log("🚀 ~ file: map-container.vue:107 ~ onComplete ~ data:", data);

  const lngLat = [data.position.lng, data.position.lat];

  locationArr.value = lngLat;

}



function onError(data: any) {

  console.log("🚀 ~ file: map-container.vue:113 ~ onError ~ data:", data);

  // 定位出错

}



onMounted(() => {

  initMap();

});

</script>



<style scoped lang="less">

#container {

  padding: 0px;

  margin: 0px;

  width: 100%;

  height: 100%;

}

</style>

MySQL 高级（进阶）SQL 语句

1. MySQL SQL 语句

1.1 常用查询

常用查询简单来说就是 增、删、改、查

对 MySQL 数据库的查询，除了基本的查询外，有时候需要对查询的结果集进行处理。 例如只取 10 条数据、对查询结果进行排序或分组等等

1、按关键字排序
PS:类比于windows 任务管理器
使用 SELECT 语句可以将需要的数据从 MySQL 数据库中查询出来，如果对查询的结果进行排序，可以使用 ORDER BY 语句来对语句实现排序，并最终将排序后的结果返回给用户。这个语句的排序不光可以针对某一个字段，也可以针对多个字段

（1）语法
SELECT column1, column2, … FROM table_name ORDER BY column1, column2, …

ASC|DESC
ASC 是按照升序进行排序的，是默认的排序方式，即 ASC 可以省略。SELECT 语句中如果没有指定具体的排序方式，则默认按 ASC方式进行排序。

DESC 是按降序方式进 行排列。当然 ORDER BY 前面也可以使用 WHERE 子句对查询结果进一步过滤。

准备工作：

create database k1;

use k1;

create table location (Region char(20),Store_Name char(20));

insert int0 location values('East','Boston');

insert int0 location values('East','New York');

insert int0 location values('West','Los Angeles');

insert int0 location values('West','Houston');

create table store_info (Store_Name char(20),Sales int(10),Date char(10));

insert int0 store_info values('Los Angeles','1500','2020-12-05');

insert int0 store_info values('Houston','250','2020-12-07');

insert int0 store_info values('Los Angeles','300','2020-12-08');

insert int0 store_info values('Boston','700','2020-12-08');

1.2 SELECT

显示表格中一个或数个字段的所有数据记录 语法：SELECT "字段" FROM "表名";

SELECT Store_Name FROM location;

SELECT Store_Name FROM Store_Info;

1.3 DISTINCT

不显示重复的数据记录

语法：SELECT DISTINCT "字段" FROM "表名";

SELECT DISTINCT Store_Name FROM Store_Info;

1.4 AND OR

且 或

语法：SELECT "字段" FROM "表名" WHERE "条件1" {[AND|OR] "条件2"}+ ;

1.5 in

显示已知的值的数据记录

语法：SELECT "字段" FROM "表名" WHERE "字段" IN ('值1', '值2', ...);

SELECT * FROM store_info WHERE Store_Name IN ('Los Angeles', 'Houston');

1.6 BETWEEN

显示两个值范围内的数据记录

语法：SELECT "字段" FROM "表名" WHERE "字段" BETWEEN '值1' AND '值2';

2. 通配符 —— 通常与 LIKE 搭配 一起使用

% ：百分号表示零个、一个或多个字符

_ ：下划线表示单个字符

'A_Z'：所有以 'A' 起头，另一个任何值的字符，且以 'Z' 为结尾的字符串。例如，'ABZ' 和 'A2Z' 都符合这一个模式，而 'AKKZ' 并不符合 (因为在 A 和 Z 之间有两个字符，而不是一个字符)。

'ABC%': 所有以 'ABC' 起头的字符串。例如，'ABCD' 和 'ABCABC' 都符合这个模式。 '%XYZ': 所有以 'XYZ' 结尾的字符串。例如，'WXYZ' 和 'ZZXYZ' 都符合这个模式。

'%AN%': 所有含有 'AN'这个模式的字符串。例如，'LOS ANGELES' 和 'SAN FRANCISCO' 都符合这个模式。

'_AN%'：所有第二个字母为 'A' 和第三个字母为 'N' 的字符串。例如，'SAN FRANCISCO' 符合这个模式，而 'LOS ANGELES' 则不符合这个模式。

2.1 LIKE

匹配一个模式来找出我们要的数据记录

语法：SELECT "字段" FROM "表名" WHERE "字段" LIKE {模式};

SELECT * FROM store_info WHERE Store_Name like '%os%';

2.2 ORDER BY

按关键字排序

语法：SELECT "字段" FROM "表名" [WHERE "条件"] ORDER BY "字段" [ASC, DESC];

注意：ASC 是按照升序进行排序的，是默认的排序方式。 DESC 是按降序方式进行排序

SELECT Store_Name,Sales,Date FROM store_info ORDER BY Sales DESC;

3. 函数

3.1数学函数

SELECT abs(-1), rand(), mod(5,3), power(2,3), round(1.89);

SELECT round(1.8937,3), truncate(1.235,2), ceil(5.2), floor(2.1), least(1.89,3,6.1,2.1);

3.2 聚合函数

SELECT avg(Sales) FROM store_info;



SELECT count(Store_Name) FROM store_info;

SELECT count(DISTINCT Store_Name) FROM store_info;



SELECT max(Sales) FROM store_info;

SELECT min(Sales) FROM store_info;



SELECT sum(Sales) FROM store_info;

3.3 字符串函数

如 sql_mode 开启了 PIPES_AS_CONCAT，"||" 视为字符串的连接操作符而非或运算符，和字符串的拼接函数Concat相类似，这和Oracle数据库使用方法一样的

SELECT Region || ' ' || Store_Name FROM location WHERE Store_Name = 'Boston';

SELECT substr(Store_Name,3) FROM location WHERE Store_Name = 'Los Angeles';

SELECT substr(Store_Name,2,4) FROM location WHERE Store_Name = 'New York'

SELECT TRIM ([ [位置] [要移除的字符串] FROM ] 字符串);

**[位置]：的值可以为 LEADING (起头), TRAILING (结尾), BOTH (起头及结尾)。 **

[要移除的字符串]：从字串的起头、结尾，或起头及结尾移除的字符串。缺省时为空格。

SELECT TRIM(LEADING 'Ne' FROM 'New York');

 

SELECT Region,length(Store_Name) FROM location;

 

SELECT REPLACE(Region,'ast','astern')FROM location;

4. GR0UP BY

对GR0UP BY后面的字段的查询结果进行汇总分组，通常是结合聚合函数一起使用的

GR0UP BY 有一个原则

• 凡是在 GR0UP BY 后面出现的字段，必须在 SELECT 后面出现；


• 凡是在 SELECT 后面出现的、且未在聚合函数中出现的字段，必须出现在 GR0UP BY 后面

语法：SELECT "字段1", SUM("字段2") FROM "表名" GR0UP BY "字段1";

SELECT Store_Name, SUM(Sales) FROM store_info GR0UP BY Store_Name ORDER BY sales desc;

5. 别名

字段別名 表格別名

语法：SELECT "表格別名"."字段1" [AS] "字段別名" FROM "表格名" [AS] "表格別名";

SELECT A.Store_Name Store, SUM(A.Sales) "Total Sales" FROM store_info A GR0UP BY A.Store_Name;

6. 子查询

子查询也被称作内查询或者嵌套查询，是指在一个查询语句里面还嵌套着另一个查询语 句。子查询语句是先于主查询语句被执行的，其结果作为外层的条件返回给主查询进行下一 步的查询过滤

连接表格，在WHERE 子句或 HAVING 子句中插入另一个 SQL 语句

语法：SELECT "字段1" FROM "表格1" WHERE "字段2" [比较运算符] #外查询 (SELECT "字段1" FROM "表格2" WHERE "条件"); #内查询

[比较运算符]

可以是符号的运算符，例如 =、>、<、>=、<= ；也可以是文字的运算符，例如 LIKE、IN、BETWEEN

SELECT SUM(Sales) FROM store_info WHERE Store_Name IN

(SELECT Store_Name FROM location WHERE Region = 'West');



SELECT SUM(A.Sales) FROM store_info A WHERE A.Store_Name IN

(SELECT Store_Name FROM location B WHERE B.Store_Name = A.Store_Name);

7. EXISTS

用来测试内查询有没有产生任何结果，类似布尔值是否为真 #如果有的话，系统就会执行外查询中的SQL语句。若是没有的话，那整个 SQL 语句就不会产生任何结果。

语法：SELECT "字段1" FROM "表格1" WHERE EXISTS (SELECT \* FROM "表格2" WHERE "条件");

SELECT SUM(Sales) FROM store_info WHERE EXISTS (SELECT * FROM location WHERE Region = 'West');

8. 连接查询

准备工作

create database k1;

use k1;

create table location (Region char(20),Store_Name char(20));

insert int0 location values('East','Boston');

insert int0 location values('East','New York');

insert int0 location values('West','Los Angeles');

insert int0 location values('West','Houston');

create table store_info (Store_Name char(20),Sales int(10),Date char(10));

insert int0 store_info values('Los Angeles','1500','2020-12-05');

insert int0 store_info values('Houston','250','2020-12-07');

insert int0 store_info values('Los Angeles','300','2020-12-08');

insert int0 store_info values('Boston','700','2020-12-08');

UPDATE store_info SET store_name='Washington' WHERE sales=300;

inner join(内连接)：只返回两个表中联结字段相等的行

left join(左连接)：返回包括左表中的所有记录和右表中联结字段相等的记录

right join(右连接)：返回包括右表中的所有记录和左表中联结字段相等的记录

8.1 内连接

MySQL 中的内连接就是两张或多张表中同时符合某种条件的数据记录的组合。通常在 FROM 子句中使用关键字 INNER JOIN 来连接多张表，并使用 ON 子句设置连接条件，内连接是系统默认的表连接，所以在 FROM 子句后可以省略 INNER 关键字，只使用 关键字 JOIN。同时有多个表时，也可以连续使用 INNER JOIN 来实现多表的内连接，不过为了更好的性能，建议最好不要超过三个表

(1) 语法 求交集

SELECT column_name(s)FROM table1 INNER JOIN table2 ON table1.column_name = table2.column_name;

SELECT * FROM location A INNER JOIN store_info B on A.Store_Name = B.Store_Name ;

内连查询：通过inner join 的方式将两张表指定的相同字段的记录行输出出来

8.2 左连接

左连接也可以被称为左外连接，在 FROM 子句中使用 LEFT JOIN 或者 LEFT OUTER JOIN 关键字来表示。左连接以左侧表为基础表，接收左表的所有行，并用这些行与右侧参 考表中的记录进行匹配，也就是说匹配左表中的所有行以及右表中符合条件的行。

SELECT * FROM location A LEFT JOIN store_info B on A.Store_Name = B.Store_Name ;

左连接中左表的记录将会全部表示出来，而右表只会显示符合搜索条件的记录，右表记录不足的地方均为 NULL

8.3 右连接

右连接也被称为右外连接，在 FROM 子句中使用 RIGHT JOIN 或者 RIGHT OUTER JOIN 关键字来表示。右连接跟左连接正好相反，它是以右表为基础表，用于接收右表中的所有行，并用这些记录与左表中的行进行匹配

SELECT * FROM location A RIGHT JOIN store_info B on A.Store_Name = B.Store_Name ;

9. UNION ----联集

将两个SQL语句的结果合并起来，两个SQL语句所产生的字段需要是同样的数据记录种类

UNION ：生成结果的数据记录值将没有重复，且按照字段的顺序进行排序

语法：[SELECT 语句 1] UNION [SELECT 语句 2];

SELECT Store_Name FROM location UNION SELECT Store_Name FROM store_info;

UNION ALL ：将生成结果的数据记录值都列出来，无论有无重复

语法：[SELECT 语句 1] UNION ALL [SELECT 语句 2];

SELECT Store_Name FROM location UNION ALL SELECT Store_Name FROM store_info;

9.1 交集值

取两个SQL语句结果的交集

SELECT A.Store_Name FROM location A INNER JOIN store_info B ON A.Store_Name = B.Store_Name;



SELECT A.Store_Name FROM location A INNER JOIN store_info B USING(Store_Name);

取两个SQL语句结果的交集，且没有重复

SELECT DISTINCT A.Store_Name FROM location A INNER JOIN store_info B USING(Store_Name);



SELECT DISTINCT Store_Name FROM location WHERE (Store_Name) IN (SELECT Store_Name FROM store_info);



SELECT DISTINCT A.Store_Name FROM location A LEFT JOIN store_info B USING(Store_Name) WHERE B.Store_Name IS NOT NULL;



SELECT A.Store_Name FROM (SELECT B.Store_Name FROM location B INNER JOIN store_info C ON B.Store_Name = C.Store_Name) A 

GR0UP BY A.Store_Name;



SELECT A.Store_Name FROM 

(SELECT DISTINCT Store_Name FROM location UNION ALL SELECT DISTINCT Store_Name FROM store_info) A 

GR0UP BY A.Store_Name HAVING COUNT(*) > 1;

9.2 无交集值

显示第一个SQL语句的结果，且与第二个SQL语句没有交集的结果，且没有重复

SELECT DISTINCT Store_Name FROM location WHERE (Store_Name) NOT IN (SELECT Store_Name FROM store_info);



SELECT DISTINCT A.Store_Name FROM location A LEFT JOIN store_info B USING(Store_Name) WHERE B.Store_Name IS NULL;



SELECT A.Store_Name FROM 

(SELECT DISTINCT Store_Name FROM location UNION ALL SELECT DISTINCT Store_Name FROM store_info) A 

GR0UP BY A.Store_Name HAVING COUNT(*) = 1;

10. case

是 SQL 用来做为 IF-THEN-ELSE 之类逻辑的关键字

语法：

SELECT CASE ("字段名")

  WHEN "条件1" THEN "结果1"

  WHEN "条件2" THEN "结果2"

  ...

  [ELSE "结果N"]

  END

FROM "表名";

"条件" 可以是一个数值或是公式。 ELSE 子句则并不是必须的。

SELECT Store_Name, CASE Store_Name 

  WHEN 'Los Angeles' THEN Sales * 2 

  WHEN 'Boston' THEN 2000

  ELSE Sales 

  END 

"New Sales",Date 

FROM store_info;



#"New Sales" 是用于 CASE 那个字段的字段名。

11. 正则表达式

语法：SELECT "字段" FROM "表名" WHERE "字段" REGEXP {模式};

SELECT * FROM store_info WHERE Store_Name REGEXP 'os';

SELECT * FROM store_info WHERE Store_Name REGEXP '^[A-G]';

SELECT * FROM store_info WHERE Store_Name REGEXP 'Ho|Bo';

12. 存储过程

存储过程是一组为了完成特定功能的SQL语句集合。

存储过程在使用过程中是将常用或者复杂的工作预先使用SQL语句写好并用一个指定的名称存储起来，这个过程经编译和优化后存储在数据库服务器中。当需要使用该存储过程时，只需要调用它即可。存储过程在执行上比传统SQL速度更快、执行效率更高。

存储过程的优点：

1、执行一次后，会将生成的二进制代码驻留缓冲区，提高执行效率

2、SQL语句加上控制语句的集合，灵活性高

3、在服务器端存储，客户端调用时，降低网络负载

4、可多次重复被调用，可随时修改，不影响客户端调用

5、可完成所有的数据库操作，也可控制数据库的信息访问权限

12.1 创建存储过程

DELIMITER $$							#将语句的结束符号从分号;临时改为两个$$(可以是自定义)

CREATE PROCEDURE Proc()					#创建存储过程，过程名为Proc，不带参数

-> BEGIN								#过程体以关键字 BEGIN 开始

-> select * from Store_Info;			#过程体语句

-> END $$								#过程体以关键字 END 结束

DELIMITER ;								#将语句的结束符号恢复为分号

实例

DELIMITER $$							#将语句的结束符号从分号;临时改为两个$$(可以自定义)

CREATE PROCEDURE Proc5()				#创建存储过程，过程名为Proc5，不带参数

-> BEGIN								#过程体以关键字 BEGIN 开始

-> create table user (id int (10), name char(10),score int (10));

-> insert int0 user values (1, 'cyw',70);

-> select * from cyw;			        #过程体语句

-> END $$								#过程体以关键字 END 结束

DELIMITER ;								#将语句的结束符号恢复为分号

12.2 调用存储过程

CALL Proc;

12.3 查看存储过程

SHOW CREATE PROCEDURE [数据库.]存储过程名; #查看某个存储过程的具体信息

SHOW CREATE PROCEDURE Proc;



SHOW PROCEDURE STATUS [LIKE '%Proc%'] \G

12.4 存储过程的参数

**IN 输入参数：**表示调用者向过程传入值（传入值可以是字面量或变量）

**OUT 输出参数：**表示过程向调用者传出值(可以返回多个值)（传出值只能是变量）

**INOUT 输入输出参数：**既表示调用者向过程传入值，又表示过程向调用者传出值（值只能是变量）

DELIMITER $$				

CREATE PROCEDURE Proc6(IN inname CHAR(16))		

-> BEGIN					

-> SELECT * FROM store_info WHERE Store_Name = inname;

-> END $$					

DELIMITER ;					



CALL Proc6('Boston');

12.5 修改存储过程

ALTER PROCEDURE <过程名>[<特征>... ]

ALTER PROCEDURE GetRole MODIFIES SQL DATA SQL SECURITY INVOKER;

MODIFIES sQLDATA:表明子程序包含写数据的语句

SECURITY:安全等级

invoker:当定义为INVOKER时，只要执行者有执行权限，就可以成功执行。

12.6 删除存储过程

存储过程内容的修改方法是通过删除原有存储过程，之后再以相同的名称创建新的存储过程。如果要修改存储过程的名称，可以先删除原存储过程，再以不同的命名创建新的存储过程。

DROP PROCEDURE IF EXISTS Proc;		

#仅当存在时删除，不添加 IF EXISTS 时，如果指定的过程不存在，则产生一个错误

13. 条件语句

if-then-else ···· end if

mysql> delimiter $$

mysql> 

mysql> CREATE PROCEDURE proc8(IN pro int)

    -> 

    -> begin

    -> 

    -> declare var int; 

    -> set var=pro*2;

    -> if var>=10 then 

    -> update t set id=id+1;

    -> else

    -> update t set id=id-1;

    -> end if;

    -> end $$



mysql> delimiter ;

14. 循环语句

while ···· end while

mysql> delimiter $$

mysql> 

mysql> create procedure proc9()

    -> begin 

    -> declare var int(10);  

    -> set var=0;

    -> while var<6 do 

    -> insert int0 t values(var);

    -> set var=var+1;

    -> end while;

    -> end $$ 



mysql> delimiter ;

15. 视图表 create view

15.1 视图表概述

视图，可以被当作是虚拟表或存储查询。

视图跟表格的不同是，表格中有实际储存数据记录，而视图是建立在表格之上的一个架构，它本身并不实际储存数据记录。

临时表在用户退出或同数据库的连接断开后就自动消失了，而视图不会消失。
视图不含有数据，只存储它的定义，它的用途一般可以简化复杂的查询。

比如你要对几个表进行连接查询，而且还要进行统计排序等操作，写sql语句会很麻烦的，用视图将几个表联结起来，然后对这个视图进行查询操作，就和对一个表查询一样，很方便。

15.2 视图表能否修改？

首先我们需要知道，视图表保存的是select语句的定义，所以视图表可不可以修改需要视情况而定。

• 如果 select 语句查询的字段是没有被处理过的源表字段，则可以通过视图表修改源表数据；


• 如果select 语句查询的字段是被 gr0up by语句或 函数 处理过的字段，则不可以直接修改视图表的数据。

create view v_store_info as select store_name,sales from store_info;



update v_store_info set sales=1000 where store_name='Houston';

create view v_sales as select store_name,sum(sales) from store_info gr0up by store_name having sum(sales)>1000;



update v_sales set store_name='xxxx' where store_name='Los Angeles';

15.3 基本语法

15.3.1 创建视图表

语法

create view "视图表名" as "select 语句";

create view v_region_sales as select a.region region,sum(b.sales) sales from location a 

inner join store_info b on a.store_name = b.store_name gr0up by region;

15.4 查看视图表

语法

select * from 视图表名;

select * from v_region_sales;

15.5 删除视图表

语法

drop view 视图表名;

drop view v_region_sales;

15.6 通过视图表求无交集值

将两个表中某个字段的不重复值进行合并

只出现一次（count =1 ） ，即无交集

通过

create view 视图表名 as select distinct 字段 from 左表 union all select distinct 字段 from 右表;



select 字段 from 视图表名 gr0up by 字段 having count(字段)=1;

#先建立视图表

create viem v_union as select distinct store_name from location union all select distinct store_name from store_info;

#再通过视图表求无交集

select store_name from v_union gr0up by store_name having count(*)=1;

大家好，我是三友~~

今天就应某位小伙伴的要求，来讲一讲Nacos作为服务注册中心底层的实现原理

不知你是否跟我一样，在使用Nacos时有以下几点疑问：

• 临时实例和永久实例是什么？有什么区别？


• 服务实例是如何注册到服务端的？


• 服务实例和服务端之间是如何保活的？


• 服务订阅是如何实现的？


• 集群间数据是如何同步的？CP还是AP？


• Nacos的数据模型是什么样的？


• ...

本文就通过探讨上述问题来探秘Nacos服务注册中心核心的底层实现原理。

虽然Nacos最新版本已经到了2.x版本，但是为了照顾那些还在用1.x版本的同学，所以本文我会同时去讲1.x版本和2.x版本的实现

临时实例和永久实例

临时实例和永久实例在Nacos中是一个非常非常重要的概念

之所以说它重要，主要是因为我在读源码的时候发现，临时实例和永久实例在底层的许多实现机制是完全不同的

临时实例

临时实例在注册到注册中心之后仅仅只保存在服务端内部一个缓存中，不会持久化到磁盘

这个服务端内部的缓存在注册中心届一般被称为服务注册表

当服务实例出现异常或者下线之后，就会把这个服务实例从服务注册表中剔除

永久实例

永久服务实例不仅仅会存在服务注册表中，同时也会被持久化到磁盘文件中

当服务实例出现异常或者下线，Nacos只会将服务实例的健康状态设置为不健康，并不会对将其从服务注册表中剔除

所以这个服务实例的信息你还是可以从注册中心看到，只不过处于不健康状态

这是就是两者最最最基本的区别

当然除了上述最基本的区别之外，两者还有很多其它的区别，接下来本文还会提到

这里你可能会有一个疑问

为什么Nacos要将服务实例分为临时实例和永久实例?

主要还是因为应用场景不同

临时实例就比较适合于业务服务，服务下线之后可以不需要在注册中心中查看到

永久实例就比较适合需要运维的服务，这种服务几乎是永久存在的，比如说MySQL、Redis等等

MySQL、Redis等服务实例可以通过SDK手动注册

对于这些服务，我们需要一直看到服务实例的状态，即使出现异常，也需要能够查看时实的状态

所以从这可以看出Nacos跟你印象中的注册中心不太一样，他不仅仅可以注册平时业务中的实例，还可以注册像MySQL、Redis这个服务实例的信息到注册中心

在SpringCloud环境底下，一般其实都是业务服务，所以默认注册服务实例都是临时实例

当然如果你想改成永久实例，可以通过下面这个配置项来完成

spring

  cloud:

    nacos:

      discovery:

        #ephemeral单词是临时的意思，设置成false，就是永久实例了

        ephemeral: false

这里还有一个小细节

在1.x版本中，一个服务中可以既有临时实例也有永久实例，服务实例是永久还是临时是由服务实例本身决定的

但是2.x版本中，一个服务中的所有实例要么都是临时的要么都是永久的，是由服务决定的，而不是具体的服务实例

所以在2.x可以说是临时服务和永久服务

为什么2.x把临时还是永久的属性由实例本身决定改成了由服务决定?

其实很简单，你想想，假设对一个MySQL服务来说，它的每个服务实例肯定都是永久的，不会出现一些是永久的，一些是临时的情况吧

所以临时还是永久的属性由服务本身决定其实就更加合理了

服务注册

作为一个服务注册中心，服务注册肯定是一个非常重要的功能

所谓的服务注册，就是通过注册中心提供的客户端SDK（或者是控制台）将服务本身的一些元信息，比如ip、端口等信息发送到注册中心服务端

服务端在接收到服务之后，会将服务的信息保存到前面提到的服务注册表中

1、1.x版本的实现

在Nacos在1.x版本的时候，服务注册是通过Http接口实现的

代码如下

整个逻辑比较简单，因为Nacos服务端本身就是用SpringBoot写的

但是在2.x版本的实现就比较复杂了

2、2.x版本的实现

2.1、通信协议的改变

2.x版本相比于1.x版本最主要的升级就是客户端和服务端通信协议的改变，由1.x版本的Http改成了2.x版本gRPC

gRPC是谷歌公司开发的一个高性能、开源和通用的RPC框架，Java版本的实现底层也是基于Netty来的

之所以改成了gRPC，主要是因为Http请求会频繁创建和销毁连接，白白浪费资源

所以在2.x版本之后，为了提升性能，就将通信协议改成了gRPC

根据官网显示，整体的效果还是很明显，相比于1.x版本，注册性能总体提升至少2倍

虽然通信方式改成了gRPC，但是2.x版本服务端依然保留了Http注册的接口，所以用1.x的Nacos SDK依然可以注册到2.x版本的服务端

2.2、具体的实现

Nacos客户端在启动的时候，会通过gRPC跟服务端建立长连接

这个连接会一直存在，之后客户端与服务端所有的通信都是基于这个长连接来的

当客户端发起注册的时候，就会通过这个长连接，将服务实例的信息发送给服务端

服务端拿到服务实例，跟1.x一样，也会存到服务注册表

除了注册之外，当注册的是临时实例时，2.x还会将服务实例信息存储到客户端中的一个缓存中，供Redo操作

所谓的Redo操作，其实就是一个补偿机制，本质是个定时任务，默认每3s执行一次

这个定时任务作用是，当客户端与服务端重新建立连接时（因为一些异常原因导致连接断开）

那么之前注册的服务实例肯定还要继续注册服务端（断开连接服务实例就会被剔除服务注册表）

所以这个Redo操作一个很重要的作用就是重连之后的重新注册的作用

除了注册之外，比如服务订阅之类的操作也需要Redo操作，当连接重新建立，之前客户端的操作都需要Redo一下

小总结

1.x版本是通过Http协议来进行服务注册的

2.x由于客户端与服务端的通信改成了gRPC长连接，所以改成通过gRPC长连接来注册

2.x比1.x多个Redo操作，当注册的服务实例是临时实例是，出现网络异常，连接重新建立之后，客户端需要将服务注册、服务订阅之类的操作进行重做

这里你可能会有个疑问

既然2.x有Redo机制保证客户端与服务端通信正常之后重新注册，那么1.x有类似的这种Redo机制么？

当然也会有，接下往下看。

心跳机制

心跳机制，也可以被称为保活机制，它的作用就是服务实例告诉注册中心我这个服务实例还活着

在正常情况下，服务关闭了，那么服务会主动向Nacos服务端发送一个服务下线的请求

Nacos服务端在接收到请求之后，会将这个服务实例从服务注册表中剔除

但是对于异常情况下，比如出现网络问题，可能导致这个注册的服务实例无法提供服务，处于不可用状态，也就是不健康

而此时在没有任何机制的情况下，服务端是无法知道这个服务处于不可用状态

所以为了避免这种情况，一些注册中心，就比如Nacos、Eureka，就会用心跳机制来判断这个服务实例是否能正常

在Nacos中，心跳机制仅仅是针对临时实例来说的，临时实例需要靠心跳机制来保活

心跳机制在1.x和2.x版本的实现也是不一样的

1.x心跳实现

在1.x中，心跳机制实现是通过客户端和服务端各存在的一个定时任务来完成的

在服务注册时，发现是临时实例，客户端会开启一个5s执行一次的定时任务

这个定时任务会构建一个Http请求，携带这个服务实例的信息，然后发送到服务端

在Nacos服务端也会开启一个定时任务，默认也是5s执行一次，去检查这些服务实例最后一次心跳的时间，也就是客户端最后一次发送Http请求的时间

• 当最后一次心跳时间超过15s，但没有超过30s，会把这服务实例标记成不健康


• 当最后一次心跳超过30s，直接把服务从服务注册表中剔除

这就是1.x版本的心跳机制，本质就是两个定时任务

其实1.x的这个心跳还有一个作用，就是跟上一节说的gRPC时Redo操作的作用是一样的

服务在处理心跳的时候，发现心跳携带这个服务实例的信息在注册表中没有，此时就会添加到服务注册表

所以心跳也有Redo的类似效果

2.x心跳实现

在2.x版本之后，由于通信协议改成了gRPC，客户端与服务端保持长连接，所以2.x版本之后它是利用这个gRPC长连接本身的心跳来保活

一旦这个连接断开，服务端就会认为这个连接注册的服务实例不可用，之后就会将这个服务实例从服务注册表中提出剔除

除了连接本身的心跳之外，Nacos还有服务端的一个主动检测机制

Nacos服务端也会启动一个定时任务，默认每隔3s执行一次

这个任务会去检查超过20s没有发送请求数据的连接

一旦发现有连接已经超过20s没发送请求，那么就会向这个连接对应的客户端发送一个请求

如果请求不通或者响应失败，此时服务端也会认为与客户端的这个连接异常，从而将这个客户端注册的服务实例从服务注册表中剔除

所以对于2.x版本，主要是两种机制来进行保活：

• 连接本身的心跳机制，断开就直接剔除服务实例


• Nacos主动检查机制，服务端会对20s没有发送数据的连接进行检查，出现异常时也会主动断开连接，剔除服务实例

小总结

心跳机制仅仅针对临时实例而言

1.x心跳机制是通过客户端和服务端两个定时任务来完成的，客户端定时上报心跳信息，服务端定时检查心跳时间，超过15s标记不健康，超过30s直接剔除

1.x心跳机制还有类似2.x的Redo作用，服务端发现心跳的服务信息不存在会，会将服务信息添加到注册表，相当于重新注册了

2.x是基于gRPC长连接本身的心跳机制和服务端的定时检查机制来的，出现异常直接剔除

健康检查

前面说了，心跳机制仅仅是临时实例用来保护的机制

而对于永久实例来说，一般来说无法主动上报心跳

就比如说MySQL实例，肯定是不会主动上报心跳到Nacos的，所以这就导致无法通过心跳机制来保活

所以针对永久实例的情况，Nacos通过一种叫健康检查的机制去判断服务实例是否活着

健康检查跟心跳机制刚好相反，心跳机制是服务实例向服务端发送请求

而所谓的健康检查就是服务端主动向服务实例发送请求，去探测服务实例是否活着

健康检查机制在1.x和2.x的实现机制是一样的

Nacos服务端在会去创建一个健康检查任务，这个任务每次执行时间间隔会在2000~7000毫秒之间

当任务触发的时候，会根据设置的健康检查的方式执行不同的逻辑，目前主要有以下三种方式：

• TCP


• HTTP


• MySQL

TCP的方式就是根据服务实例的ip和端口去判断是否能连接成功，如果连接成功，就认为健康，反之就任务不健康

HTTP的方式就是向服务实例的ip和端口发送一个Http请求，请求路径是需要设置的，如果能正常请求，说明实例健康，反之就不健康

MySQL的方式是一种特殊的检查方式，他可以执行下面这条Sql来判断数据库是不是主库

默认情况下，都是通过TCP的方式来探测服务实例是否还活着

服务发现

所谓的服务发现就是指当有服务实例注册成功之后，其它服务可以发现这些服务实例

Nacos提供了两种发现方式：

• 主动查询


• 服务订阅

主动查询就是指客户端主动向服务端查询需要关注的服务实例，也就是拉（pull）的模式

服务订阅就是指客户端向服务端发送一个订阅服务的请求，当被订阅的服务有信息变动就会主动将服务实例的信息推送给订阅的客户端，本质就是推（push）模式

在我们平时使用时，一般来说都是选择使用订阅的方式，这样一旦有服务实例数据的变动，客户端能够第一时间感知

并且Nacos在整合SpringCloud的时候，默认就是使用订阅的方式

对于这两种服务发现方式，1.x和2.x版本实现也是不一样

服务查询其实两者实现都很简单

1.x整体就是发送Http请求去查询服务实例，2.x只不过是将Http请求换成了gRPC的请求

服务端对于查询的处理过程都是一样的，从服务注册表中查出符合查询条件的服务实例进行返回

不过对于服务订阅，两者的机制就稍微复杂一点

在Nacos客户端，不论是1.x还是2.x都是通过SDK中的NamingService#subscribe方法来发起订阅的

当有服务实例数据变动的时，客户端就会回调EventListener，就可以拿到最新的服务实例数据了

虽然1.x还是2.x都是同样的方法，但是具体的实现逻辑是不一样的

1.x服务订阅实现

在1.x版本的时候，服务订阅的处理逻辑大致会有以下三步：

第一步，客户端在启动的时候，会去构建一个叫PushReceiver的类

这个类会去创建一个UDP Socket，端口是随机的

其实通过名字就可以知道这个类的作用，就是通过UDP的方式接收服务端推送的数据的

第二步，调用NamingService#subscribe来发起订阅时，会先去服务端查询需要订阅服务的所有实例信息

之后会将所有服务实例数据存到客户端的一个内部缓存中

并且在查询的时候，会将这个UDP Socket的端口作为一个参数传到服务端

服务端接收到这个UDP端口后，后续就通过这个端口给客户端推送服务实例数据

第三步，会为这次订阅开启一个不定时执行的任务

之所以不定时，是因为这个当执行异常的时候，下次执行的时间间隔就会变长，但是最多不超过60s，正常是10s，这个10s是查询服务实例是服务端返回的

这个任务会去从服务端查询订阅的服务实例信息，然后更新内部缓存

这里你可能会有个疑问

既然有了服务变动推送的功能，为什么还要定时去查询更新服务实例信息呢?

其实很简单，那就是因为UDP通信不稳定导致的

虽然有Push，但是由于UDP通信自身的不确定性，有可能会导致客户端接收变动信息失败

所以这里就加了一个定时任务，弥补这种可能性，属于一个兜底的方案。

这就是1.x版本的服务订阅的实现

2.x服务订阅的实现

讲完1.x的版本实现，接下来就讲一讲2.x版本的实现

由于2.x版本换成了gRPC长连接的方式，所以2.x版本服务数据变更推送已经完全抛弃了1.x的UDP做法

当有服务实例变动的时候，服务端直接通过这个长连接将服务信息发送给客户端

客户端拿到最新服务实例数据之后的处理方式就跟1.x是一样了

除了处理方式一样，2.x也继承了1.x的其他的东西

比如客户端依然会有服务实例的缓存

定时对比机制也保留了，只不过这个定时对比的机制默认是关闭状态

之所以默认关闭，主要还是因为长连接还是比较稳定的原因

当客户端出现异常，接收不到请求，那么服务端会直接跟客户端断开连接

当恢复正常，由于有Redo操作，所以还是能拿到最新的实例信息的

所以2.x版本的服务订阅功能的实现大致如下图所示

这里还有个细节需要注意

在1.x版本的时候，任何服务都是可以被订阅的

但是在2.x版本中，只支持订阅临时服务，对于永久服务，已经不支持订阅了

小总结

服务查询1.x是通过Http请求；2.x通过gRPC请求

服务订阅1.x是通过UDP来推送的；2.x就基于gRPC长连接来实现的

1.x和2.x客户端都有服务实例的缓存，也有定时对比机制，只不过1.x会自动开启；2.x提供了一个开个，可以手动选择是否开启，默认不开启

数据一致性

由于Nacos是支持集群模式的，所以一定会涉及到分布式系统中不可避免的数据一致性问题

1、服务实例的责任机制

再说数据一致性问题之前，先来讨论一下服务实例的责任机制

什么是服务实例的责任机制？

比如上面提到的服务注册、心跳管理、监控检查机制，当只有一个Nacos服务时，那么自然而言这个服务会去检查所有的服务实例的心跳时间，执行所有服务实例的健康检查任务

但是当出现Nacos服务出现集群时，为了平衡各Nacos服务的压力，Nacos会根据一定的规则让每个Nacos服务只管理一部分服务实例的

当然每个Nacos服务的注册表还是全部的服务实例数据

这个管理机制我给他起了一个名字，就叫做责任机制，因为我在1.x和2.x都提到了responsible这个单词

本质就是Nacos服务对哪些服务实例负有心跳监测，健康检查的责任。

2、CAP定理和BASE理论

谈到数据一致性问题，一定离不开两个著名分布式理论

• CAP定理


• BASE理论

CAP定理中，三个字母分别代表这些含义：

• C，Consistency单词的缩写，代表一致性，指分布式系统中各个节点的数据保持强一致，也就是每个时刻都必须一样，不一样整个系统就不能对外提供服务


• A，Availability单词的缩写，代表可用性，指整个分布式系统保持对外可用，即使从每个节点获取的数据可能都不一样，只要能获取到就行


• P，Partition tolerance单词的缩写，代表分区容错性。

所谓的CAP定理，就是指在一个分布式系统中，CAP这三个指标，最多同时只能满足其中的两个，不可能三个都同时满足

为什么三者不能同时满足？

对于一个分布式系统，网络分区是一定需要满足的

而所谓分区指的是系统中的服务部署在不同的网络区域中

比如，同一套系统可能同时在北京和上海都有部署，那么他们就处于不同的网络分区，就可能出现无法互相访问的情况

当然，你也可以把所有的服务都放在一个网络分区，但是当网络出现故障时，整个系统都无法对外提供服务，那这还有什么意义呢？

所以分布式系统一定需要满足分区容错性，把系统部署在不同的区域网络中

此时只剩下了一致性和可用性，它们为什么不能同时满足？

其实答案很简单，就因为可能出现网络分区导致的通信失败。

比如说，现在出现了网络分区的问题，上图中的A网络区域和B网络区域无法相互访问

此时假设往上图中的A网络区域发送请求，将服务中的一个值 i 属性设置成 1

如果保证可用性，此时由于A和B网络不通，此时只有A中的服务修改成功，B无法修改成功，此时数据AB区域数据就不一致性，也就没有保证数据一致性

如果保证一致性，此时由于A和B网络不通，所以此时A也不能修改成功，必须修改失败，否则就会导致AB数据不一致

虽然A没修改成功，保证了数据一致性，AB还是之前相同的数据，但是此时整个系统已经没有写可用性了，无法成功写数据了。

所以从上面分析可以看出，在有分区容错性的前提下，可用性和一致性是无法同时保证的。

虽然无法同时一致性和可用性，但是能不能换种思路来思考一下这个问题

首先我们可以先保证系统的可用性，也就是先让系统能够写数据，将A区域服务中的i修改成1

之后当AB区域之间网络恢复之后，将A区域的i值复制给B区域，这样就能够保证AB区域间的数据最终是一致的了

这不就皆大欢喜了么

这种思路其实就是BASE理论的核心要点，优先保证可用性，数据最终达成一致性。

BASE理论主要是包括以下三点：

• 基本可用（Basically Available）：系统出现故障还是能够对外提供服务，不至于直接无法用了


• 软状态（Soft State）：允许各个节点的数据不一致


• 最终一致性，（Eventually Consistent）：虽然允许各个节点的数据不一致，但是在一定时间之后，各个节点的数据最终需要一致的

BASE理论其实就是妥协之后的产物。

3、Nacos的AP和CP

Nacos其实目前是同时支持AP和CP的

具体使用AP还是CP得取决于Nacos内部的具体功能，并不是有的文章说的可以通过一个配置自由切换。

就以服务注册举例来说，对于临时实例来说，Nacos会优先保证可用性，也就是AP

对于永久实例，Nacos会优先保证数据的一致性，也就是CP

接下来我们就来讲一讲Nacos的CP和AP的实现原理

3.1、Nacos的AP实现

对于AP来说，Nacos使用的是阿里自研的Distro协议

在这个协议中，每个服务端节点是一个平等的状态，每个服务端节点正常情况下数据是一样的，每个服务端节点都可以接收来自客户端的读写请求

当某个节点刚启动时，他会向集群中的某个节点发送请求，拉取所有的服务实例数据到自己的服务注册表中

这样其它客户端就可以从这个服务节点中获取到服务实例数据了

当某个服务端节点接收到注册临时服务实例的请求，不仅仅会将这个服务实例存到自身的服务注册表，同时也会向其它所有服务节点发送请求，将这个服务数据同步到其它所有节点

所以此时从任意一个节点都是可以获取到所有的服务实例数据的。

即使数据同步的过程发生异常，服务实例也成功注册到一个Nacos服务中，对外部而言，整个Nacos集群是可用的，也就达到了AP的效果

同时为了满足BASE理论，Nacos也有下面两种机制保证最终节点间数据最终是一致的：

• 失败重试机制


• 定时对比机制

失败重试机制是指当数据同步给其它节点失败时，会每隔3s重试一次，直到成功

定时对比机制就是指，每个Nacos服务节点会定时向所有的其它服务节点发送一些认证的请求

这个请求会告诉每个服务节点自己负责的服务实例的对应的版本号，这个版本号随着服务实例的变动就会变动

如果其它服务节点的数据的版本号跟自己的对不上，那就说明其它服务节点的数据不是最新的

此时这个Nacos服务节点就会将自己负责的服务实例数据发给不是最新数据的节点，这样就保证了每个节点的数据是一样的了。

3.2、Nacos的CP实现

Nacos的CP实现是基于Raft算法来实现的

在1.x版本早期，Nacos是自己手动实现Raft算法

在2.x版本，Nacos移除了手动实现Raft算法，转而拥抱基于蚂蚁开源的JRaft框架

在Raft算法，每个节点主要有三个状态

• Leader，负责所有的读写请求，一个集群只有一个


• Follower，从节点，主要是负责复制Leader的数据，保证数据的一致性


• Candidate，候选节点，最终会变成Leader或者Follower

集群启动时都是节点Follower，经过一段时间会转换成Candidate状态，再经过一系列复杂的选择算法，选出一个Leader

这个选举算法比较复杂，完全值得另写一篇文章，这里就不细说了。不过立个flag，如果本篇文章点赞量超过28个，我连夜爆肝，再来一篇。

当有写请求时，如果请求的节点不是Leader节点时，会将请求转给Leader节点，由Leader节点处理写请求

比如，有个客户端连到的上图中的Nacos服务2节点，之后向Nacos服务2注册服务

Nacos服务2接收到请求之后，会判断自己是不是Leader节点，发现自己不是

此时Nacos服务2就会向Leader节点发送请求，Leader节点接收到请求之后，会处理服务注册的过程

为什么说Raft是保证CP的呢？

主要是因为Raft在处理写的时候有一个判断过程

• 首先，Leader在处理写请求时，不会直接数据应用到自己的系统，而是先向所有的Follower发送请求，让他们先处理这个请求


• 当超过半数的Follower成功处理了这个写请求之后，Leader才会写数据，并返回给客户端请求处理成功


• 如果超过一定时间未收到超过半数处理成功Follower的信号，此时Leader认为这次写数据是失败的，就不会处理写请求，直接返回给客户端请求失败

所以，一旦发生故障，导致接收不到半数的Follower写成功的响应，整个集群就直接写失败，这就很符合CP的概念了。

不过这里还有一个小细节需要注意

Nacos在处理查询服务实例的请求直接时，并不会将请求转发给Leader节点处理，而是直接查当前Nacos服务实例的注册表

这其实就会引发一个问题

如果客户端查询的Follower节点没有及时处理Leader同步过来的写请求（过半响应的节点中不包括这个节点），此时在这个Follower其实是查不到最新的数据的，这就会导致数据的不一致

所以说，虽然Raft协议规定要求从Leader节点查最新的数据，但是Nacos至少在读服务实例数据时并没有遵守这个协议

当然对于其它的一些数据的读写请求有的还是遵守了这个协议。

JRaft对于读请求其实是做了很多优化的，其实从Follower节点通过一定的机制也是能够保证读到最新的数据

数据模型

在Nacos中，一个服务的确定是由三部分信息确定

• 命名空间（Namespace）：多租户隔离用的，默认是public


• 分组（Gr0up）：这个其实可以用来做环境隔离，服务注册时可以指定服务的分组，比如是测试环境或者是开发环境，默认是DEFAULT_GR0UP


• 服务名（ServiceName）：这个就不用多说了

通过上面三者就可以确定同一个服务了

在服务注册和订阅的时候，必须要指定上述三部分信息，如果不指定，Nacos就会提供默认的信息

不过，在Nacos中，在服务里面其实还是有一个集群的概念

在服务注册的时候，可以指定这个服务实例在哪个集体的集群中，默认是在DEFAULT集群下

在SpringCloud环境底下可以通过如下配置去设置

spring

  cloud:

    nacos:

      discovery:

        cluster-name: sanyoujavaCluster

在服务订阅的时候，可以指定订阅哪些集群下的服务实例

当然，也可以不指定，如果不指定话，默认就是订阅这个服务下的所有集群的服务实例

我们日常使用中可以将部署在相同区域的服务划分为同一个集群，比如杭州属于一个集群，上海属于一个集群

这样服务调用的时候，就可以优先使用同一个地区的服务了，比跨区域调用速度更快。

总结

到这，终终终于总算是讲完了Nacos作为注册中心核心的实现原理

1 ELK日志系统

经典的ELK架构或现被称为Elastic Stack。Elastic Stack架构为Elasticsearch + Logstash + Kibana + Beats的组合：

• Beats负责日志的采集


• Logstash负责做日志的聚合和处理


• ES作为日志的存储和搜索系统


• Kibana作为可视化前端展示

整体架构图：

2 EFK日志系统

容器化场景中，尤其k8s环境，用户经常使用EFK架构。F代表Fluent Bit，一个开源多平台的日志处理器和转发器。Fluent Bit可以：

• 让用户从不同来源收集数据/日志


• 统一并发到多个目的地


• 完全兼容Docker和k8s环境

3 PLG日志系统

3.1 Prometheus+k8s日志系统

PLG

Grafana Labs提供的另一个日志解决方案PLG逐渐流行。PLG架构即Promtail + Loki + Grafana的组合：

Grafana，开源的可视化和分析软件，允许用户查询、可视化、警告和探索监控指标。Grafana主要提供时间序列数据的仪表板解决方案，支持超过数十种数据源。

Grafana Loki是一组可以组成一个功能齐全的日志堆栈组件，与其它日志系统不同，Loki只建立日志标签的索引而不索引原始日志消息，而是为日志数据设置一组标签，即Loki运营成本更低，效率还提高几个数量级。

Loki设计理念

Prometheus启发，可实现可水平扩展、高可用的多租户日志系统。Loki整体架构由不同组件协同完成日志收集、索引、存储等。

各组件如下，Loki’s Architecture深入了解。Loki就是like Prometheus, but for logs。

Promtail是一个日志收集的代理，会将本地日志内容发到一个Loki实例，它通常部署到需要监视应用程序的每台机器/容器上。Promtail主要是用来发现目标、将标签附加到日志流以及将日志推送到Loki。截止到目前，Promtail可以跟踪两个来源的日志：本地日志文件和systemd日志（仅支持AMD64架构）。

4 PLG V.S ELK

4.1 ES V.S Loki

ELK/EFK架构确实强，经多年实际环境验证。存储在ES中的日志通常以非结构化JSON对象形式存储在磁盘，且ES为每个对象都建索引，以便全文搜索，然后用户可特定查询语言搜索这些日志数据。

而Loki数据存储解耦：

• 既可在磁盘存储


• 也可用如Amazon S3云存储系统

Loki日志带有一组标签名和值，只有标签对被索引，这种权衡使它比完整索引操作成本更低，但针对基于内容的查询，需通过LogQL再单独查询。

4.2 Fluentd V.S Promtail

相比Fluentd，Promtail专为Loki定制，它可为运行在同一节点的k8s Pods做服务发现，从指定文件夹读取日志。Loki类似Prometheus的标签方式。因此，当与Prometheus部署在同一环境，因为相同的服务发现机制，来自Promtail的日志通常具有与应用程序指标相同的标签，统一标签管理。

4.3 Grafana V.S Kibana

Kibana提供许多可视化工具来进行数据分析，高级功能如异常检测等机器学习功能。Grafana针对Prometheus和Loki等时间序列数据打造，可在同一仪表板上查看日志指标。

参考

• http://www.javaedge.cn/#/special

已经在一家 AI 公司入职了一个月，对坐班有些厌恶的我，没想到有一天也会开始通勤打卡。而经历了这一个月的工作，我对坐班的态度有所转变，开始理解这种工作方式对我的意义。是时候分享入职这期间的工作内容与感受。

背景

直入正题，先说职位背景。该职位的技术要求大致如下，仅做参考。

## 任职要求 

1. 本科及以上学历，计算机科学、软件工程等相关专业, 硕士优先； 

2. 扎实的 HTML、CSS、JavaScript 基础(vanilla) 功底 ； 

3. 熟练使用 React、React Native 和 Next.js 进行前端开发 

4. 了解前端性能优化技术，如代码压缩、懒加载等 

5. 熟悉前端工程化工具 

6. 具备良好的问题解决能力和团队协作精神 

7. 熟练阅读英文技术文档 

8. 有优异前端项目开发经验者优先 



## 加分项： 

- 贡献开源社区 

- 有 AI 相关项目经验。 

- 有前端性能优化和 SEO 优化经验。 

- 有良好的产品思维和设计(UI/UX)意识。 

- 有同理心思维。

- 具有一定的审美感。