国庆回来又出 Bug 了，简单复盘一下，总结下来还是碰到的问题不够多，经验不够老道。 背景 国庆期间上线了一个签到类的业务，且流量较大，节前配合 QA 测试测了好久，没想到还是出问题了。 问题描述 节后有用户反馈说签到不了，且反馈的用户不止一两个，这时候应该就猜到可能是出现问题了，随即开始排查。 先检查代码，看了半天也没发现问题。（期间别的同事也帮我看了，也没发现问题） 查数据，看了下线上的数据发现完成 7 天（全部）签到的人也挺多的，也没看出来问题。然后再看了下其中几个签到不了的用户的数据，发现了罪魁祸首，如下图 2： 我立马想到了我写的那段逻辑，问题出现在这里，用户签到时间是 2024-10-06 23:59:59 我计算缓存的过期时间是当天的 23:59:59-签到的时间， 导致设置了 0 ，0 表示这几个缓存永不过期，而这个缓存标志 todaySignKey 是

最近项目上有个需求是根据账号所获得的积分来做一个全局的积分排行榜，并且要求同积分时先达到的排名靠前，而不是并列排名，只取前10名的数据，活动时间不会持续太久，一个月左右。 技术方案选型 前置要求（2C4G1副本）： 响应时间：接口平均响应时间均小于500ms，99%响应时间均小于1s。 TPS：场景TPS均大于1K，满足性能需求。 资源使用：每个场景执行完之后，CPU、内存会慢慢恢复至执行前状态，符合正常情况，满足性能需求。 错误率：各场景执行过程中，接口错误率为0。 1. 基于数据库实现排行榜 由于大多数项目都是采用关系型数据库MySQL，以下以MySQL举例。 首先，排序很容易想到用order by score, update_time，然后 取 limit 10，这样就能拿到前10名的数据，然后需要提升性能需要对score, update_time 加索引。 最后总结一下：

从 0 到 1 搭建日志收集系统 - Loki Loki 是由Grafana出品的日志收集系统，它是由Go语言开发的，具有轻量、占用内存低、易部署等优点。但是需要搭配使用Grafana生态中的promtail以及就是grafana面板进行使用。 为什么选择Loki 1. 日志是刚需 目前，各种服务都是以容器的方式部署至云服务器中，以及基本都是多个微服务，查看日志相比之前的单体服务而言也就麻烦了许多，那么有没有一种聚合日志的方式来查看呢？那当然是有的，不然遇到几十上百个微服务的情况查看起日志来及其不方便。日志平台的作用主要目的是为了收集各个项目的服务日志，以及快速检索到错误日志等功能，基于这种背景下日志平台也就成了刚需。 2. 节省资源 Loki相较于传统的日志采集系统 ELK (Elasticsearch, Kibana & Logstash) 来说，内存占用低、易部署这两个优

OAuth2 是什么 OAuth2.0 是目前行业标准的在线授权协议，用于允许一个网站或应用程序在用户授权的情况下访问其他 web apps 托管的资源。它基于 Access Tokens，提供授权并限制客户端应用程序执行的操作，同时不需要共享用户的凭据。 OAuth2 的核心概念 OAuth2 的核心概念包括： Redircect URI：重定向 URI 是客户端应用程序接收授权码的 URL。 Authorization Endpoint：授权终端是用于验证用户身份并颁发授权码的服务器端点。 Access Token：访问令牌是用于访问受保护资源的令牌。 Refresh Token：刷新令牌是用于更新访问令牌的令牌。 Scope：范围是指定访问令牌权限的参数。 Client ID：客户端 ID 是用于标识客户端应用程序的唯一标识符。 Client Secret：客户端密钥是用于验证客户

讲一讲 Golang 中 excelize 的几种用法 excelize[^1]是 golang 中一个操作excel的库，有点类似于 Java 生态中阿里巴巴开源的EasyExcel[^2]。 导出 1. 直接生成 excel 文件 应用场景：常用于脚本读取 DB（database）中的数据导出成 excel 文件。 func main() { // Create a new sheet. f := excelize.NewFile() // MOCK的数据 list := []PendingData{ {Brand: "abc.com", TLD: "100/100", Include: "100/100", Typo: "100/100", Added: "2024-02-17"}, {Brand: "abcasdf.com", TLD: "100/100"