base36 encode/decode 不是本来就不用额外内存吗？ 何来省内存的说法。
另外现在搞这种东西都是用 simd 了，一个个字节处理太慢了

先把 A{data: "a"}和 A{data: "b"}构造好, 循环里直接换它们的指针就不会有错,
我猜测顺序是 alloc 内存 -> 更新指针 -> 给 string 赋值, 所以出现了不是 a 或 b 的情况.

用 map 也是换汤不换药啊, 正确做法是在 struct 里加 tag, 然后这里反射遍历结构体再存 excel 吧.

find + sort 为什么不行, 这不是最简单的办法吗?

速度 30-40 毫秒的话, 我觉得很有可能是用 for 循环查了 300 次 redis, 或者是连 redis 的网络不行. 想个办法写成一句查询, 一次性返回 300 个结果.

如果新 md5 大概率不在这 100 万个里面, 可以外面套一层 bloomfilter, 减少查询量.

交通 30 吃饭 60, 没了.

考算法题没问题, 就是有些面试官总是要求回答他从答案里看来的最优的做法,
比如链表检测环的问题, 能用 dfs 做就足够了, 却一定要回答快慢指针的做法.
好歹也是 floyd 发明的算法, 如果没见过怎么可能一下子想出来.

查表你还要额外内存呢, 用 seed 产生随机数不比查表好?

@drymonfidelia 因为 n % 64 == n & (63), 而 base62 和 base36 不行, 就这么简单.

不是有 base64url 吗?

pg 里可以写 python 之类的很多编程语言.

一般是这样搞的.
1. 把完整的请求通过消息队列存到 OLAP 数据库里, 在离线的情况下用 count(*) group by 查.
2. 在线数据直接对数据库 update x = x + 1 where ...
3. 如果数据量太大, update 性能不行, 就本地或者 redis 里存一下, 攒个 n 次或者 5s 的定时器触发
一次性 update x = x + n
4. 因为有离线数据库, 可以比较在线库是不是漏数据了, 有 bug 就找出来修一下, 一般就是服务器重启的时候丢的.

kafka 在这起什么作用? rpc 调用就会导致任务丢失了?

把 explain 贴出来看看, 如果里面有 hash semi join ,那就说明是机器性能太差了, 否则就是 sql 要改.

@unknown404 这是下载, 不是上传.

https://github.com/xiaoyaocz/dart_simple_live 可以看斗鱼虎牙抖音直播

真的有场景是不得不用分布式事务的吗?
我遇到过的情况都是对数据库的事务理解不行, 然后搞了一套恶心人的分布式事务上去.

type Node struct {
Left *Node
Right *Node
Val int
}
type TreeVisiter struct {
root *Node
}

func makeNode(val int) *Node {
return &Node{Val: val}
}

func (fr *TreeVisiter) InOrder(visit func(*Node) bool) {
fr.p_inOrder(visit, fr.root)
}

func (fr *TreeVisiter) p_inOrder(visit func(*Node) bool, cur *Node) {
if cur.Left != nil {
if !visit(cur.Left) {
return
}
}
if !visit(cur) {
return
}
if cur.Right != nil {
if !visit(cur.Right) {
return
}
}
}

func main() {
root := makeNode(2)
root.Left = makeNode(1)
root.Right = makeNode(3)
tv := TreeVisiter{root: root}
for node := range tv.InOrder {
if node.Val == 1 {
fmt.Printf("first node is %d\n", node.Val)
}
if node.Val == 2 {
fmt.Printf("second node is %d\n", node.Val)
break
}
}
}


中序遍历二叉树, 这个至少比 cpp 的 begin,end 好多了,
我公司项目里写的 cpp 的用来遍历树的 forward_iterator 写了快 300 行, 虽然情况也比这个复杂很多.