前言 MySQL和Redis，这两个都是在项目中常用的工具，MySQL作为数据的持久化保证，虽然说在MySQL默认的存储引擎InnoDB中比较好的平衡了「高性能和高可靠」，但是如果想应对互联网的大型流量上，可能还是捉襟见肘甚至可能导致整个系统崩溃。 公认的项目中通常是「读多写少」的情况，换言之可能在大部分时候数据不是那么多变的。因此缓存的引入可以解决读多情况。 Redis是什么 这里不长篇的介绍Redis的各个细节，我们先来讨论一下缓存是什么？缓存其实本质来说就是「空间换时间」的概念，在常见的系统设计时候，无一例外都会使用到缓存这个思想，例如解析URL的DNS服务器存在缓存、InnoDB中的Buffer Pool也是缓存的一种思想。 回到Redis来说，Redis单实例的读QPS可以达到10w/s，其实足以因对大部分场景了。 使用缓存的思想 在此之前我先简单的谈一谈，我对新技术引入的一些思

前言 在实习的过程中我遇到了多个需要对接第三方平台的工作，那么对接的时候我应该考虑什么或者是我应该注意什么。 因此这一篇文章就尝试总结一下吧 经常需要考虑的点 封装统一的Http请求工具类 这一点很好理解，其实就是为了去更好的复用代码 打印请求接口入参、出参、耗时日志 参数的合法性校验 减少对下游无效的调用 例如，数据格式的校验、业务合法性的校验 接口设置超时超时时间 不同的业务场景设置不同的超时时间 接口是否需要重试以及重试的次数需要考虑 需要考虑一下下游接口提供的能力，注意事务接口不要重试 查询类接口重试，也是需要考虑的因为要考虑下游接口QPS的支持 多次调用改为单次批量调用 接口返回的数据考虑是否缓存 如果返回数据理论上在长时间内都不会改变，可以使用redis进行缓存

前言 每当引入一个新的技术在项目中，一定是为了解决某个问题从而提升性能，当然不可避免的会增加维护成本以及技术本身需要考虑的问题。那么就来总结一下当项目引入了消息队列之后，需要去关注的一些常见问题 如何处理消费过程中的重复消息 如何确保消息不丢失 如何保证消息的顺序消费 消息积压了应该如何处理 如何处理消费过程中的重复消息 在消息传递过程中，如果传递失败那么发送方会执行重试，而这个重试的过程就可以会出现重复的消息。 可能会有第一直觉想到说，如果我的消息队列本身消息就是没有重复，那么业务程序不就简单多了吗？ 在常见的消息队列中都是遵守At least once，也就是至少一次，消息在传递的过程中，至少会被送达一次，也就是说不允许丢消息，但是允许有少量重复消息出现。 说的这里要避免消费过程中的重复消息，本质还是需要让代码“接受”重复，也就是要让代码能过消除重复消息对业务的影响。 用幂等性来解

📝记录一下在实习遇到的一个线上Bug，整体排查解决链路（已脱敏）。 🤔为什么要写这一个总结呢？问题其实很简单，但是其中的排查步骤是值得思考的，如何将这次经验抽象成通用的解决步骤，这个才是关键所在！。 省流版：因为一张表索引没有设置好，导致的后续一系列的问题！ 问题的发现 客户的工单：产品的xxx页面修改操作无法响应，卡死。 定位问题 出现这个问题，第一个需要查看的就是日志和监控系统，可是！项目没有部署监控和日志系统😢 紧急部署内部的监控工具 分析 监控日志分析 通过日志可以发现，在某个时间的时候开始出现锁超时问题其中，xxx_todo表被锁住了。在业务中该表对应着我们其中待办模块。 从上述日志得到的信息就是，xxx_todo表被锁了，该表对应的是待办模块，判断问题的方向为待办相关定时任务 定时任务日志分析 通过拉取数据，找到定时任执行记录，可以锁定到「消息机制」待办定时任务执行

前言 本篇文章就来记录一下HTTP的S究竟是什么？ HTTP大家一定都是十分熟悉了，那么HTTP与HTTPS有什么不同呢？ 多了个S HTTP是明文传输，容易有安全性的问题 HTTPS是会加密传输的，并且需要CA证书 其实HTTPS重点是在这个S上，也就是SSL/TLS这就是HTTPS的核心，所以本篇文章也是从这两个进行展开的。 加密安全协议 SSL其实是TLS的前生它们都是安全加密协议，目前大部分浏览器都不支持SSL，而支持TLS。 到这里可以很清楚的知道，HTTPS需要保证安全性，那么就一定需要对数据进行加密，所以接下来先来说一说加密的知识吧。 对称加密 通俗来说，对称加密就是双方都是使用相同的加密规则，那么这个就称为对称加密。 那么如果有第三方知道这个加密规则，那么就有风险被破解了。 非对称加密 首先，先来讲讲如何得到一个安全的密钥。 首先用户A和用户B都拥有一个公钥