没有优雅的实现。
其他语言可以给拿数据的连接设置 read timeout ，或者用子进程来处理。
但是 Go 把连接给封装了，大部分数据库的接口是同步的，你没法同时监听 fd 可读和定时器超时。
子进程要传数据需要用 pipe ，但是它的 Read()/Write() 是同步的，需要再起个协程去读写，才能和监听子进程退出和超时一起 select 。而且 Go 的 runtime 和第三方库可能都跑了一些子线程，fork 时并不会复制这些子线程，导致有时候会崩溃。

如果类型兼容，用 unsafe.Pointer 转，但是 []any 不行

a := []int{1, 2, 3}
b := *(*[]uint)(unsafe.Pointer(&a))
fmt.Println(b)
c := *(*[]float32)(unsafe.Pointer(&a))
fmt.Println(c)
d := *(*[]float64)(unsafe.Pointer(&a))
fmt.Println(d)
e := *(*[]any)(unsafe.Pointer(&a))
fmt.Println(e)

如果是做接口的话，不建议用 []any ，直接用 any ，然后做类型检查，文档中注明比较好。

InnoDB 的一页默认是 16KB ，其中有 100 多字节是头部等不用于存储数据的，这里先忽略。
索引页的每行要存储一个主键（假设是 int ，4 字节）和一个页号（ 4 字节），共计 8 字节。即一页最多存储 2K 条。
以一个 3 层的 B+ 树来计算，前两层是索引页，最多索引 2K * 2K = 4M 个节点。
假设表的每行占用的空间是 1KB ，那么一个数据页（叶子节点）最多存储 16 条数据，所有节点共可以存储 64M 条数据（ 64GB 大小）。
超过这个量时，要用 4 层的 B+ 树，那么 IO 次数就至少多出 1/3 ，索引也很难全放在内存中，肯定会大幅影响性能。

但是题目中提到的 500M 行和 2GB 并不是一个固定值，如果主键和每行占用的空间较小，就能存放更多的页。甚至你还能修改 innodb_page_size ，配置成更大的页，以在一页中存储更多行（但是可能造成 IO 的浪费，因为每次至少读一页）。

你自己加个锁不就行了吗？ sync.Map 单独实现出来是因为可以分片加锁，这样不同的 cpu 访问不同的分片时可以不用加锁，而其他数据结构没有这样的优化方法。

因为换安卓了

自用就 ubuntu ，别 centos ，不然你想折腾都得自己编译

提前下载、挂代理

也可能是硬盘慢。。

静态语言不好搞任务队列啊，给你一个字符串 "xxx.func"，你都没法通过反射找到并调用这个函数

我这个可以
https://github.com/keakon/golog
https://github.com/keakon/golog/blob/master/writer.go#L322

原因是这个 https://github.com/shadowsocks/shadowsocks-libev/issues/361#issuecomment-130538207

Python 2 可以这样设置：
```
import socket
import IN
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.connect(('65.55.42.21', 3074))
s.setsockopt(socket.IPPROTO_IP, IN.IP_MTU_DISCOVER, IN.IP_PMTUDISC_DONT)
s.send('010000003b0017000000000058626f78204f6e65204563686f205465737400'.decode('hex'))
s.recvfrom(65565)
```

dns 解析的时间不算在 timeout 里，你只有一个域名的话，写在 hosts 里让它不解析不就行了？

如果解析的文件是 json 的话，市面上所有的 json 库都会内存泄露

@waibunleung 你最好先熟悉 redis 的内存占用再来臆测。一楼的方案内存占用要多 1~2 个数量级。

总视频数、每 10 分钟总的访问量说下量级吧，应用场景是怎样的，感觉你想得太多了。

比如「我想做一个管理后台…」，你管理后台每秒能刷几千次啊，还能被刷爆？

而如果是面向公众用户的场景，你的需求也不需要「实时、精确地计算出访问增量」，每分钟统计一下就行了。

最后，这种情况比较常见的做法是使用时间轮，比如选一个比 10 大又能被 60 整除的数，例如 12 。将当前的分钟数对 12 取模，然后每个 key 记录这一分钟的数据。每到一个新的一分钟，就把 11 分钟前的 key 删了。要获取数据时，就取当前和之前的 10 个 key 。
至于数据结构选啥，根据你的视频量级、视频数是否恒定、id 是否连续等而定，不同的方案内存差别很大。比如一楼提到的 view_count_{vid}_{minute}，这种实现不用看也知道内存扛不住。

原因是这个
https://redis.io/commands/scan#why-scan-may-return-all-the-items-of-an-aggregate-data-type-in-a-single-call

只有当底层实现是 hash table 的时候，cursor 才有意义。出于内存优化的考虑，较小的数据结构（比如只有 2 个 key ），redis 会用 compact single-allocation packed encoding 。这种编码下强行使用 cursor 会导致时间复杂度变成 O(n)，所以会直接返回所有数据。

不知道你的业务场景是怎样的，我弄了 1 万个 set，每个 set 1000 个整数，sunionstore 1 万次不同的 set 也就 200 多 ms 。但是因为修改比较多，会触发 bgsave，可以关闭掉在 slave 去做。

如果这也是瓶颈的话，在应用层读出来合并再写回去会慢一个数量级。
不过如果不需要保存 sunionstore 的结果，这样虽然慢，但是可以节省 redis 的 CPU 。

这样管控，多个人怎么并行开发？

Python 没有 i++ 啊