我们写一些请求时会需要用到分布式锁，主要是为了防连击或一些基础的幂等操作。最简单的方式那肯定是用redis的set加上nx和px/ex参数来实现，利用redis串行操作的天然原子性很方便搞出来，只是发现写的人多了，一个人一个用法，有的忘了加过期，有的忘了解锁，有的干脆懒得就不写了，于是抽象出一个公共方法来搞，解放下生产力。 方法使用非常简单。 原使用方法 rnum := rand.Intn(1000) key := fmt.Sprintf("interface1:%s:%s:%s", param1,param2,param3) flag, err := redisCli.SetNX(ctx, key, rnum, 3*time.Second).Result() if err != nil { return err } if !flag { return errors.New("request locking") } //do some work num, err := redisCli.Get(ctx, key) if err == nil && num == rnum {
前几天看自己一个关于用户信息的代码，突然发现组里一个人加了一段与之并列的逻辑，看着像是重构的方法，心想这个模块上线才不到一个月，也没发现有什么问题，为什么要重新搞？于是去问提交的人原因，他的意思是原来有两点问题，需要优化，现在新产品用户量还不高，等高了可能有问题，我觉得有必要记下来，聊一下这个cache需要怎么更新 数据结构 数据其实就是一个用户信息表，包含用户id，用户名，各种用户资料之类的，包含一个DB表，DB之前会有一个redis用于cache信息。很典型的cache方式 原cache-set流程（双删更新） 删除redis中对应修改用户key的数据 update用户信息表 delay 1s左右再次删除对应用户key的数据 请求用户数据时判断cache存在，则直接返回 请求用户数据时判断cache不存在，读db 读db后将数据json_encode到字符串set到redis中 返回db结果 新cache-set流程 update用户信息表 订阅用户信息表binlog 解析更新内容，修改redis中对应用户的hash结果中的修改内容的字段key 请求用户数据判断cache存在
因为最近需要做一个滑动窗口式的限流器，本着不要重复造轮子的原则找一些开源的，但找了半天发现都是些单机版的，没办法就自己搞一个吧 不多介绍，就是一个基于redis的sorted-set写的滑动窗口式的频率控制器，可以支持多种限流策略组合，适合类似于push这类的需要频控的业务 Just show the code https://github.com/elangx/redis-ratelimiter
平时我们在调一些rpc/db数据或获取一些远程setting时，常常会把他们保存在本地cache里，但每次又需要考虑存本地全局变量还是cache组件，还要考虑序列化反序列化，保存时间，数据结构调整之类的事，导致一些类似的工作会搞好几遍。于是我就搞了这个duration_cache的东西，他只需要在你原先读取数据的基础上调整一行代码就可以帮你把数据保存起来，过期后再重新获取，一般是不需要考虑结构调整，也不自己处理过期，使用了泛型，所以支持所有类型数据。 具体本地缓存用的freecache，因为它支持单key过期时间，同时使用了zero-gc的策略，保证了性能，不过也不时动态扩容；另外有个点是每个key大小不能大于千分之一的总容量 另外使用了singleflight来保证不会有并发更新的问题 使用方法很简单： 原代码示例： cacheRs, err := cache.GetUser(ctx, 1234) if err == nil && cacheRs != nil { return cacheRs, nil } row, err := db.GetUser(ctx, 1234) if
记得最早做app大家都提lamp，学会这4个就完事 现在写个代码，做个系统，设计个架构高低得k8s一下，k8s一来，那链路追踪、微服务监控、服务发现、稳定性方案之类的哗哗的就来了，那多了这么多东西，除了显得高大上，吹牛逼外，实际上多了什么好处？ 微服务的目的 我觉得就是2个点 解决复杂的业务： 业务涉及面比较广，一个或少量模块会让业务逻辑过于集中，使得代码越来越复杂，越来越庞大，耦合严重 在将要进行重构改造时会发现历史包袱特别重，很容易迁一发而动全身 稳定性不好，可能产生二级服务出问题拖垮一级服务的问题 扩容不方便，CPU密集型服务和io密集型服务对于扩容需求不一样 解决复杂的人： 参数业务的人数据太多，一个团队十几个人改同一个模块，可能会常常要去解冲突 不同的人不同的想法，一个模块很容易出现很多种不同风格的代码 代码互相耦合但又不互相负责，导致很容易带着别人的bug代码上线 微服务当前问题 有能力要微，没能力也要微 一些团队为了能解决好上面两个点，带入了微服务，但微服务又需要一整套链路才可以发挥一个好的作用，而这套架构需要一个完整的基础、运维团队来维护，这是一笔成
eLangX
不要瞎写！不要瞎写！不要瞎写！
