本文目录一览：
- 1、【golang】海量数据去重-布隆过滤器
- 2、golang elasticsearch指标聚合（metrics） --- 2022-04-02
- 3、golang 数组去重去空怎么实现比较高效
- 4、为什么很多程序员不用switch，而是大量的if……else if？
【golang】海量数据去重-布隆过滤器
在做域名爆破中，遇到了把一个300G的子域名json文件进行去重，一开始是考虑使用字典进行去重，但是数据量大了，会造成内存泄露。看网上资料介绍了一种方案，就是使用布隆过滤器。
布隆过滤器是一种数据结构，概率型数据结构，特定是高效插入和查询，可以用来告诉你“某一值一定不存在或者kennel存在”。
相比于传统的map、set等数据结构，占用空间更少，但其返回结果是概率型的，不确定。
布隆过滤器内部维护一个bitArray(位数组)，开始所有数据为0，当一个元素过来时，能过多个哈希函数（hash1、hash2、hash3）计算不同的hash值，并通过hash值找到bitArray的下标，将里面的值改为由0变为1。布隆过滤器有一个误判率，误判率越低，数组越长，所在空间越大，误判率越高，数组越小，所占空间越小。
这里贴上一个技术大牛的博客地址，里面对布隆过滤器用法以及在redis里面处理缓存穿透问题的详细介绍。
golang elasticsearch指标聚合（metrics） --- 2022-04-02
ES指标聚合，就是类似SQL的统计函数，指标聚合可以单独使用，也可以跟桶聚合一起使用，下面介绍golang如何使用ES的指标聚合。
不了解ES指标聚合相关知识，先看一下 Elasticsearch 指标聚合教程
值聚合，主要用于统计文档总数，类似SQL的count函数。
基数聚合，也是用于统计文档的总数，跟Value Count的区别是，基数聚合会去重，不会统计重复的值，类似SQL的count(DISTINCT 字段)用法。
求平均值
求和计算
求最大值
求最小值
golang 数组去重去空怎么实现比较高效
一种高效算法的大概思想：
设置一个循环用来遍历数组，一个慢一步，，一个快一步，当到了数组末尾或者快的与慢的下标对应的元素相等就退出，，退出循环后再检测“快的与慢的下标对应的元素相等”这一条件，如果是就说明有重复元素。否则没有。
为什么很多程序员不用switch，而是大量的if……else if？
我个人觉得switch其实非常多余。
1 大部分场景，都是2到3个可能分支，用个if else就可以了，除非有4 个以上分支，太多else显得不好看，才考虑用switch.
2 switch限制多。switch必须是常量变量。if后面可以写任意表达式。
3用法复杂，case后面要么break,要么return,要是不写，居然还会继续执行剩下的分支，对于新手来说分分钟掉坑。
4 写法上其实也不比if else优雅简洁，switch xxx case xxxx ….
所以，switch徒增复杂性，真的不怎么实用。
如果有10000种switch的可能性，有1000000个值需要被处理，怕是你们说的这些个switch的好处就完全消失了，预期平均每次要比较5000次，1000000个值，总计要比较50亿次，不知道你们的CPU是啥主频能扛得住这个计算量，针对这种情况的终极武器还是hash，根据不同的语言，hash的value可以是匿名函数，可以是接口的不同实现，用hash来快速确定处理算法，而不是switch
答案：主要因为switch不适合业务系统的实际复杂需求，业务不断的变更迭代，一更改需求，条件的复杂度高了，switch无力处理。
switch优点
那么什么时候适合switch，它的场景是：基于单一变量的值（如枚举），这样的可读性比if条件更清晰。
switch缺点
从上面的场景来看，实在太局限，我来简单说一下它的一些缺点吧：
1. 现实的业务场景很复杂，条件不单一，一旦需求变更，维护代码相当崩溃。
2. switch经常忘记写break，估计很多人一不小心就忘记写了。如果你看过google的代码规范，你会发现，Google对switch的要求非常多。
switch的封装才更灵活
其实switch有人还在用也有一部分是 历史 原因，但是随着 科技 的发展，原有的设计以及落后了。
有些编程语言，如Python都没有switch这种语法。当然也有部分新语言Golang和Kotlin还是继承下来，但是又把switch包装了一下，去掉了令人误会的语法，这才让switch变得灵活起来了。 如果不封装，很难用。
IF语句的好处
通过上面描述的缺点也就是if语句更灵活的地方，根据业务进行逻辑条件编写，可维护性高。同时只要写的代码质量高，可读性也就会更高。
建议
现实的业务实际是很复杂的，我也不建议一定要用大量的if……else if,而是应该尽早返回来减少嵌套，这样增加了可读性以及降低维护的成本。
从C/ C++来看，当分支较多且switch要比较的值是连续的话，执行速度远远远远快于if，因为switch是直接跳到目标代码执行的，而if则需要执行很多条语句，慢的不是一点点，一般编译器会根据分支数量和比较的值是否连续生成不同汇编代码，如果编译器判定不能提升速度的话，switch生成的汇编代码和if是一模一样的没有任何区别。
至于很多人不用switch我觉得可能是:
1.为了方便写代码，思维习惯随手就用if写了;
2.可能根本就不懂为什么要用switch吧。
作为程序员来说，我更喜欢switch的结构，更直观更容易找到相应的代码块。不过为什么很多程序员不用Switch，而是使用大量的if...else if的结构，甚至像Python已经不支持原生Switch语法了？
这个原因很简单，因为switch语法结构最后编译还是通过if...else if来完成代码的，所以从效率角度来说和if...else if一样的。但是switch对比条件比较单一，绝大多数支持switch的编程语言都支持等于比较，也就是说变量只能等于case中的条件才会执行代码块。但是现实情况中，对比条件绝大多数比单一等于运算要复杂得多，因此很多程序员就直接使用if...else if。但是if...else if的结构，后期维护起来会比较不清晰，毕竟没有Case...Break那么直观。但是添加一些注解应该还是能解决这个问题的。
所以，我现在能使用Switch的时候还是会使用switch，毕竟后期代码维护起来方便点。不过更多时候还是用if...else if。
送大家以下java学习资料
我曾经接手过一份代码，遇到过一个三十几个if else套if else的模块。
心理骂骂咧咧谁他喵写的这玩意，然后开始review 历史 。
大致情况是这样的：第一个程序员写下这段代码时，只有两个if else；后来开始逐渐加需求，先是一个、两个，随后量变引起质变，于是逻辑分支快速扩张。
这个时候已经没有人愿意去重构成switch或是其他什么设计模式了，毕竟复杂度摆在那里，万一崩了还得背锅。
三四个程序员接手这段代码之后，就变成我现在这种局面了。
第一个程序员绝对没有料到这么简单的逻辑在之后会变成这么复杂的模块，甚至在增添第一第二条else时，也只是很随意的加上。
所以我觉得，这个锅绝对是是甲方的，让他娘的随便改需求。
这么一想心里就好受多了，编程嘛，最重要的是要看的开。
于是我又增加了两条else，测试，提交，下班。
有时候真的不是我们不想写好代码，是不能写好代码。写着写着需求砍了、需求变了，什么设计模式都不顶用，最终还是怎样快怎样方便怎样来，因为根本没人知道这段代码还能不能活的过下一段需求变动。
有的人肯定要说怎么不订合同。合同肯定是有的，但是明明白纸黑字写的合同，该改还是得改，毕竟你要是不同意甲方那些“微小的变动”，以后还做不做了？！金主真能去得罪？
还是要学会得过且过，跟什么过不去也不能跟自己过不去，糟糕的代码忍一忍就完了:代码能跑、头发不少，对我们这些打工的人而言比什么都重要。
现实工作绝不是课本中的理想状态，会有无数的突发情况在等着你。你定义了半天观察者、备忘录，第二天这部分需求被砍了；写了半天接口，抽象类，忽然下午告诉你要加个十万八千里打不着边的啥东西，于是又开始加适配器，等你加完了告诉你又砍了。甚至有次半夜被喊起来改代码，等改完了发现需求被撤回了，气的我直接请了两天假调整心情。
设计模式和大的框架绝对是一个项目中非常重要的东西，但不是绝对重要的；一个好的PM团队，在某种意义上，才真正决定了这个项目的代码质量。[1]
请用5秒钟的时间查看下面的代码是否存在bug。
OK，熟练的程序猿应该已经发现Bug所在了，在第8行和第10行下面我没有添加关键字break; 这就导致这段代码的行为逻辑与我的设计初衷不符了。
缺点一. 语法正确，逻辑错误
这就是第一个理由为什么程序猿很少使用switch来做条件判断，对于新手来说忘记写break实在是再普通不过了，就算是老猿忘记写也是时有发生的事情，而这个语法错误在诸多的语法检查器上没有办法检查出来的，因为从语法角度来说是正确的！可是代码的处理逻辑却是错误的！用if来重写这段代码的话，就不会发生这种错误。
上面的代码为了保证正确我添加了else做一个逻辑上的保证，其实如果不写else，这段代码也不会发生逻辑错误，而且一旦我忘记写花括号的时候，语法编译器是会提示我添加的，甚至可以使用eslint这种的工具强制我使用花括号，这样就不会犯语法错误了，一旦出现bug，那么肯定是我逻辑上的问题了。
缺点二 .死板的语法
switch尽管对于break很宽容，但是对判断条件很严苛，case后面只能跟常量，如果你用C编写的话，甚至只能用int类型作为判断条件。对于我们这么潇洒自如的程序猿来说，这种限制实在是太麻烦了，用if的话，别说是常量了，我用函数都可以，真正做到方便快捷。
缺点三 .需要子函数来处理分支
这个缺点跟缺点一有关，为了防止漏写break，因此建议把分支处理方法独立成一个子函数来处理，这样在阅读代码的时候就会减少忘记写break带来的bug，那么用if来写的话，我想怎么写就怎么写，非常随意自由，但是这也导致了代码的可读性大大降低。
switch的优点
既然switch有这么严重的缺点，那怎么在所有语言中依然会存在呢？那就说下switch的优点吧，它的优点也刚好是它的缺点。
在很久很久以前，那时候的电脑性能还不如一台小霸学习机的时候，聪明的计算机科学家为了提高计算机的处理速度，将一些逻辑分支处理方法简化了一下，把一些需要做逻辑判断的操作给固定死，然后只要查表一样一个一个对一下就能做出相应的反应了。
比如说a=0的判断，switch和if在cpu上面的处理方式是不一样的，switch是在编译阶段将子函数的地址和判断条件绑定了，只要直接将a的直接映射到子函数地址去执行就可以了，但是if处理起来就不一样了。
它首先要把a的值放到CPU的寄存器中，然后要把比较的值放到CPU的另一个寄存器中，然后做减法，然后根据计算结果跳转到子函数去执行，这样一来就要多出3步的操作了，如果逻辑判断多的话，那么将会比switch多处许多倍的操作，尽管寄存器操作的速度很快，但是对于当时的学习机来说，这点速度根本不够用啊。
那还有一个问题，为什么要使用break来做一个判断结束呢？这不是很容易造成语法错误了？那就要说到子函数的问题上了。
在早起的电脑代码中是没有子函数的概念的，那时候都是用goto随意跳转的，你想去第10行代码，很简单goto 10就可以了。这种编程思维在C的早期阶段还是一直受到影响的，因此早期的C也没有子函数，都是一堆逻辑处理混乱在一起，goto满天飞，所以那时候你没有一个最强大脑是写不了程序的。那为了告诉程序我这里条件判断处理结束，就添加了break作为终止符号。后来慢慢的有了子程序，有了更好的编程规范，才一步一步的将写代码沦落到体力劳动。
后来发展的新语言为了标榜自己的血统，多少都要参考下C，然后就把switch这种诡异的语法也继承下来了。但是也不是所有的语言都照搬，比如Google发明的新语言golang和kotlin就又把switch包装了一下，去掉了令人误会的语法，又让switch变得灵活起来了，对了，在代码重构的时候，还是用switch把，这样看起来的确代码更简洁哦！[2]
switch只能用于简单判断，不支持表达式。
没有if else 使用方便。
不是尽量别用，而是不合适没法用，合适得时候该用还是用。
比如说，变量i要求大于10，小于20,一条if(i10i
