weixin_44139651的博客

标签一致性：尽管Pod名称是随机的，但Pod的标签（labels）是一致的，并且与Deployment的标签选择器（selector）相匹配。稳定性：StatefulSet确保Pod的序号在Pod重新调度或重建后保持不变，这是通过StatefulSet的Pod管理策略（OrderedReady或Parallel）来实现的。Pod的序号是按照它们被创建的顺序分配的，从0开始递增。随机名称：每个Pod的名称是由Kubernetes随机生成的，通常是一个五字符的随机字符串，这些字符可能是字母和数字的组合。

这两个踩坑问题的共性其实都是代码更新了，而文档没做对应的更新。这能从源码和issue里才能发现这个问题，且报错信息不太明朗，甚至没有相关报错。导致没办法直接解决，也没想过文档会有问题。接触新东西更新快，处于beta不稳定阶段。应该有这个意识，以最新代码和readme为准。有问题解决不了，最好的办法就是去找源码。深入源码才有可能根本解决问题。

但我们的环境是K8S集群，节点之间理应是隔离的，所以猜想是storage挂载了同一个目录的问题，修改PV，两个PV挂载的目录不同，改为storageSlave。需要在开发环境部署rocketmq5验证新版本proxy相关的特性，而开发环境没有helm和外网，有k8s的环境。由于是root用户账号，k8s启动用的kubectl账号，把挂载的目录移到了/tmp，修改上文PV文件。注意，转成yaml文件后，原本用helm设置的namespace没了。网上查了下是挂载的本地目录，pod没有权限读写。

如果EXTERNAL-IP设置了该值，则您的环境具有可用于入口网关的外部负载平衡器。如果EXTERNAL-IP值是（或永久），则您的环境不为入口网关提供外部负载平衡器。在这种情况下，您可以使用服务的节点端口来访问网关。这里443对应的端口是Https服务的端口，映射的主机端口31390；直接官网下载后安装即可，网上也有详细教程。拉不到镜像的情况，在docker中手动拉取（由于源和超时时间等原因）这里80对应的端口是Http服务的端口，映射的主机端口31380；下载安装包，拉到机器上（github)

且由于distinct关键字会对所有字段生效，在进行复合业务处理时，group by的使用灵活性更高，group by能根据分组情况，对数据进行更为复杂的处理，例如通过having对数据进行过滤，或通过聚合函数对数据进行运算。在大多数例子中，DISTINCT可以被看作是特殊的GROUP BY，它们的实现都基于分组操作，且都可以通过松散索引扫描、紧凑索引扫描(关于索引扫描的内容会在其他文章中详细介绍，就不在此细致介绍了)来实现。为什么在语义相同，有索引的情况下，group by和distinct效率相同？

一致性Hash算法引入了一个虚拟节点机制，即对每个服务器节点计算出多个hash值，它们都会映射到hash环上，映射到这些虚拟节点的对象key，最终会缓存在真实的节点上。引入虚拟节点的同时也增加了新的问题，要做虚拟节点和真实节点间的映射，对象key->虚拟节点->实际节点之间的转换。想到之前十亿数据迁移的时候用到了哈希分桶，当时有同步验证一致性哈希的性能，这里记录下一致性哈希的实现方法。实现一致性哈希算法主要是为了均衡的分桶，为了避免数据倾斜的问题，加入了虚拟节点。哈希算法用的是MurMurHash3。

要首先确认约束条件，才能设计方案。确定面试官主要想问的方向，例如1T文件如何切割为小文件，虽是难点，然而可能不是面试官想考察的问题。从数据规模看，需要分库分表，大致确定分表的规模。从单库的写入瓶颈分析，判断需要进行分库。考虑到磁盘对并发写的支持力度不同，同一个库多个表写入的并发需要限制。并且支持动态调整，方便在线上环境调试出最优值。MySQL innodb、myisam 存储引擎对写入性能支持不同，也要在线上对比验证数据库批量插入的最佳阈值需要反复测试得出。

索引就是帮助MySQL高效获取数据的一种【数据结构】。索引是一种树结构，MySQL中一般用的是【B+树】。

使用join实现，但不适合join太多表，阿里巴巴开发者手册的规定，join表的数量不应该超过3个，join表数量太多时，会导致mysql在选错索引。一般SQL优化第一考虑的是索引优化，可使用explain命令，查看MySQL的执行计划，确认SQL是否有走索引。相对连接查询，子查询使用in关键字实现，具有结构化，相对简单，但是需要创建和删除临时表，增加资源消耗。索引可提升SQL效率，但索引需要额外的存储空间，而且还会有一定的性能消耗。left join，两个表的交集，以及左表剩余的数据，左表为驱动表。

如果表table_a只有一个文件，大小为120M，但包含几千万的记录，如果用1个map去完成这个任务，肯定是比较耗时的，这种情况下，我们要考虑将这一个文件合理的拆分成多个，这样就可以用多个map任务去完成。前面三个参数确定合并文件块的大小，大于文件块大小128m的，按照128m来分隔，小于128m,大于100m的，按照100m来分隔，把那些小于100m的（包括小文件和分隔大文件剩下的），进行合并。一般来讲，map 数量默认，不需要我们设置，一般情况下，Hive 自己就可以知道到底使用多少个map。

这种原本的写法感觉不是很好，会导致误解，之后接手的人不了解这里，很容易就改出问题了。其实把字符串‘NULL’，换成别的更容易理解的字符串，也是完全不影响结果的，而且更好理解。之后写代码可以注意这里。

这个需求是今年做的最大的需求了。涉及了大数据BDP HIVE，十亿级的数据迁移；Redis新集群，容量优化；迁移脚本写入Redis速度的优化；Redis抖动的兜底和恢复机制。有一些感觉上还比较巧妙的方法，起到了四两拨千斤的效果。比如使用当前年份作为Redis Set中key的一部分，能够有效避免跨年的问题，并且不设置有效期，通过年定时任务来进行去年key的清理，也避免了年中上线有效期计算的问题。方法简洁且有效的解决了需求问题。

NotePad++针对一批数据批量添加双引号和逗号以及去除空格的处理技巧

由于mysql在真正执行语句的时候，并不能准确的知道满足这个条件的记录有多少，只能通过统计信息来估算记录，而优化器并不是非常智能的，就有可能发生索引跳变的情况，这种情况很难在测试的时候复现出来，生产也可能是突然出现，所以我们只能在使用上尽量的去降低索引发生跳变的可能性，尽量避免出现该问题。我们可以在创建索引和使用sql的时候通过以下几个点进行检视。(1) 索引的创建。

项目姓名校验原本一直是通过utf8正则进行校验，但近期出现的客户生僻字包含双码字，原有校验方式无法实现。需要修改扩大校验范围。

腾讯文件存储的COS系统时而有抖动的现象，导致文件上传失败。而这些文件对客户查记录来说有很重要，所以需要一种兜底机制，在文件存储COS系统不可用的情况下，仍然能保存图片，在COS可用之后重新上传，提高系统的总体可用性

新的限流方法需要从请求中读取appid，实现appid级的限流。功能开发完在测试环境中跑没有问题，测试也没有发现问题。但上线后却直接抛异常，看了下日志，是个固定appid，从request读取的时候拿不到。仔细查看后，发现这个appid对应的客户采用的xml的格式请求，不是JSON的！解决的思路是，拿到请求后，先判断请求头里的请求格式，如果是xml格式，则先转成JSON。从网上找到两种xml转JSON的方法，详见参考文件。如果请求是xml，最后一行jackson读值的时候就会报错。

通过以上几步，就可以简单实现拦截器限流的方式。之后如果需要在服务接口响应之前做些公共操作也可以考虑拦截器的方式。方便且容易实现，步骤很清晰，可以专注于功能本身的开发。

记录一次云上排查内存泄露的问题，最近监控告警云上有空指针异常报出，于是找到运维查日志定位到具体是哪一行代码抛出的空指针异常，

RestTemplate和Spring提供的JdbcTemplate类似，对象一旦构建（使用过程中不对其属性进行修改）就是线程安全的，多线程环境下可以安全使用。第三方库提供的各种方便的类，简化了编码复杂度，方便了开发者。使用不恰当时，细微的编码可能埋藏着大的隐患。精雕细琢，精益求精。