Golang后端

一、需求 如果我们将榜单的程序部署到了多个实例，那么有可能出现以下情景和问题： 同一时刻，多个实例同时执行热榜计算的任务，导致计算资源的浪费。 即使同一时刻只有一个实例计算热榜，但控制不住别的实例再去

一、查询接口的缓存方案 现在假设我们需要暴露一个查询接口：返回前 100 榜单的文章列表。 这个查询接口就是一个高并发并且高可用的接口。你可以预期，类似于微博、小红书之类的，基本上任何用户打开网站或者

一、将计算所得的热榜数据存入 Redis 1.1 三个关键点 热榜数据我们并没有保存到数据库里面，而在一些公司里面，这个数据可能会被保存数据库里面，用于大数据分析。 在 Redis 中的过期时间，要比

一、核心的算法 考虑到文章数可能非常多，我们采用一个批量计算的方法，整个流程如上图（作者用飞书画的，u1s1还挺好用）： 从数据库中读取一批文章（batchSize），再找到对应的点赞数和时间，计算

一、需求 假定我们现在有一个业务需求：展示一个热点榜单，展示五十条（下图是我在稀土掘金首页上展示的榜单） 从非功能性上来说，热榜功能通常是作为首页的一部分，或者至少是一个高频访问的页面，因此性能和可用

一、要求 设计一个高性能方案，要求： 综合考虑可以怎么利用缓存，包括 Redis 和本地缓存，设计方案有无亮点？ 考虑怎样的业务折中？【一般由产品经理决定能接受怎样的折中方案】 绘制 UML 序列图，

一、背景 前面一文讲到如何利用 Prometheus 为 Gin 设计一个 middleware 来统计 HTTP 响应时间和活跃数量。链接：为Gin设计中间件(四)：接入Prometheus提高可观

一、重要概念 下图以某个 Consumer Group 订阅的某个 topic （该 topic 有 partition1 和 partition2 两个分区）为例 1.1 Kafka 的高性能、高扩

一、需求 设计一个新的容错机制，同步转异步的容错机制。当满足以下两个条件（触发了限流、判定服务商已经崩溃）中的任何一个时，将请求转储到数据库（画个饼：过几天更新消息队列的版本 doge），后续再另外启

一、为什么要在公司内部提到短信服务的安全性？ 如果你在一个大公司，那么类似于短信这种资源，是需要考虑安全和成本控制的。比如说利用审批流程来 申请一个 tpl（模板），里面要求业务方对自己的用量进行评估

一、背景 接上文，这篇文章分享 应对如果短信服务商真的寄了的策略二：动态判定服务商状态。不同于上文的轮询 failover 策略，本文的策略的思路是 计算服务商是否还运作正常 。常用的判断标准有：（根

一、服务商“寄”了 前文的限流是为了不触发服务商的自我保护机制。但是，万一服务商真的出了问题呢？即便服务商的可用性做到了四个九，也还是有小概率崩溃，怎么办？可以考虑在服务商出了问题的时候，切换到新的服

一、需求 我们作为用户端几乎每天都在大大小小各个平台上实现着 “手机验证码登录账号” 这个功能，但实际上，这个功能涉及了 3 个功能模块：短信模块、验证码模块和用户登录模块，模块间的关系如下图。 所以

一、背景 测试驱动开发（Test-Driven Development，简称TDD）是一种软件开发的理念，尤其在后端开发中广泛应用，其核心思想是在实际编写任何业务逻辑代码之前，先编写测试用例。 单元测

一、背景 在软件系统中，我们希望通过度量和监控系统中各组件的行为，从而了解系统的状态和性能，这种能力叫做“可观测性”。它可以帮助开发人员快速定位和解决系统中的问题，提高系统的稳定性和可靠性。可观测性分

一、背景 痛点： 对于 登录和注册模块 ，最明显的漏洞是：”任何人都可以注册，任何人都可以登录“，也就是说，万一有一个人用 shell 脚本拼命给你发注册请求、登录请求，系统负载就会很高。 若用限流，

一、背景 痛点： 用单一的 token 来实现频繁的请求，泄露后较为危险。需要有一个长 token 。这个 token 只在登录和调用 /refresh_token 时使用，所以不容易泄露。 受到微信

本文关键词：JWT、Redis实现退出登录 一、登录部分 痛点：虽然有人为 Gin 提供了 JWT 插件，但是插件过于复杂并且不好用。而且它屏蔽了和 JWT 有关的操作，不易于理解和学习，所以我们直接

需求：在web后端开发中，想输出http请求和响应的日志 思路：利用Gin提供的middleware的 AOP 机制 实现： （1）欲打印如下字段 （2）具体实现 注意：Gin 的 ctx 没有暴露响