今天在玩腾讯的vscode的ai编程插件。
看来腾讯的人都是用Mac的，不过就算不用windows，没见过马屎，但也该见过马跑呀！Windows里哪来的cmd键你倒是说说呀？ 而且，一般别人的cmd是用windows徽标键，但他不是，按照软文中ctrl-windows-i也不对。
第一张图是vscode里的codebuddy的提示。
第二张图是腾讯发的软文。
问题不大，不过真的很可笑。
上面只是笑话他们不认真测试，但有句说句，相比copilot的1000次限制，cursor的20刀一个月，腾讯这是免费全功能服务，也不用要求太高了，还是赞一下。

看来百业萧条，ovh居然也出盲盒了，基准配置是 22.99o/月，E5-1650v3 64g 2＊480ssd 1g。
本着愚人精神，我赌把手气，还不错，v3 -> v4， 2＊480 ssd -> 2＊1.2t nvme, 64g -> 128g。
~~ 卖了溢价几十百把块也没意思，还不如自己拿来乐乐吧，这么高性价比的机器真的难找。~~
~~ 1ip的博客现在挂在上面了，也不套cf了，直连吧。 ~~

(经不起高溢价的诱惑，今天已经把它出了。。。)

前因后果不扯了，我前几篇贴文都在说这个事，简单说就是上周系统大并发下炸了。
今天的流量比上周还大一倍,但数据库和服务器完全是在低负荷下运行。（数据库有的那个尖峰，是因为数据库缩容后比例尺变化显示原因，不是真的大负荷）
开心。

无语

程序在处理请求读取非实时数据时，通常会先从 Redis 缓存中获取数据。如果缓存失效或过期，程序会转而从数据库读取最新数据，然后将结果写回 Redis。听起来没问题，对吧？确实，这是标准的缓存更新流程，我最初也没觉得有什么不对。
但问题来了：在高并发场景下，事情就没那么简单了。假设缓存恰好失效，从缓存过期到新数据写入 Redis 的这段时间，哪怕只有几十毫秒就可能有无数个请求同时涌入。这些请求发现缓存没了，都会去查数据库、更新 Redis，轻则系统负荷升高，重则引起缓存混乱系统失效。我脑子不好使没转过弯，想不出啥好办法解决。后来一问ai，才发现，哎，这早就是个成熟的算法了，简单又巧妙，赶紧写下来备忘！

var dupMu sync.Mutex   //互斥锁，用来锁定缓存失效请求
func heavyLoadFunc() {
  err:=LoadFromRds(keyname, param, &list)  //读redis
  if err==nil && list!=nil {   //缓存命中直接返回数据
    ....
    return list
  }
  dupMu.Lock()     //双重缓存锁。缓存未命中，锁定，只允许一个个排队进入
  defer dupMu.Unlock()
  err:=LoadFromRds(keyname, param, &list)   //第二次读取redis。即，排队的未命中请求，第一个请求会缓存再次失败进入数据库更新redis数据，但在第一个完成后，其余请求即可从redis获得数据，防止再次更新。太巧妙和简单了。
  if err==nil && list!=nil {
    ....
    return list
  }
  list,err=getDataFromDb()  //从数据库更新
  return list  
}