现在正常了。刚刚刷 ios13，登陆不了。吓死我了

里面的商品或者地点信息,这些都是有数据库基础表维护的。
这就是简单的一个匹配的问题。
应该由后端自己处理。前端只管传话就好了。

匹配关键词的方法很多。分词，双尾后缀树，自动机等等。

里面的商品或者地点信息,这些都是有数据库基础表维护的

可以看看 https://jwt.io/ 。两个系统同时使用相同的密钥可能存在风险。 不过都是 web 应用，可以随时切换到新的密钥上。

@EasyProgramming
JWT 如果只用来验证登录，是不需要存储的。都是通过相同的密钥加密生成的。

```golang
package main

func alwaysFalse() bool {
return false
}

func main() {
switch alwaysFalse();{
case true:
println("真")
case false:
println("假")
}
}

```
多了个分号，然后语义变了。 这块确实要注意。

package main

func alwaysFalse() bool {
return false
}

func main() {
switch alwaysFalse();{
case true:
println("真")
case false:
println("假")
}
}


多了个分号，然后语义变了。 这块确实要注意。

@void1900 增加个批量操作。基本 qps 和 cpu 都降下去了，统计业务没必要实时计算。 不丢就行了。

基于 redis 做 uv 一般是 hyperLogLog。
建议可以在程序内缓存一分钟数据，然后通过 pipeline 批量导入 redis。
做好信号处理，监听退出信号，退出前停止接收数据，并强制落盘到 redis。
压力在 redis 上，换 go 不换逻辑提升不明显。

卖茶叶姑娘的升级版本。
如果不是熟人就删除吧。

https://github.com/luw2007/rabbitid 我也写了个发号器。
[需求调研]( https://github.com/luw2007/rabbitid/blob/master/doc/research.md)
为了保证多机房部署，需要一个全局 ID 生成器，支持多机房部署，一主多备。采用`ringbuffer`分批取，内存使用原子递增的方式保证高效性。支持多个存储后端如:`Redis`，`ZooKeeper`，`etcd`。

iphone 除了不会被垃圾软件监听。体验上已经没法超越 android 太多。
建议实在体验就买个二手的吧。
工资太低是关键。好好提高自己才是正途。
花钱买手机。还不如多买几本书看看。

如果是全新项目， 没有历史包袱，怎么命名觉得无伤大雅。
接口是包含在项目中。整个项目需要有统一的返回结构。

我觉得是主管的问题。这种很容易就能沟通好。主管没有能摆事实讲道理让你信服。反而让你产生离职的想法。那么就不是一个合格的管理者。

对于你的提议，我个人觉得。errCode 不如 code，errmMsg 不如 msg。简单就是美。

@JCZ2MkKb5S8ZX9pq 用户量少就不要考虑拆分活跃用户和非活跃用户。只会增加代码的复杂度。
完备的做法就是再造一个微博。

owner 发布之后，直接更新 follower 的 timeline

homeline timeline
很少会用数据库直接生成
大部分都是在发|删帖的时候用逻辑改变 homeline 和 timeline

无药可救。

@woscaizi 如果有利可图，频次限制都解决不了这种问题。帐号，代理都有人提供。频次限制总不能影响掉普通用户吧。

@pxlxh ?

以前用 go 做过 p2p 金融抢单，大致说一下软件思路。
调度进程，业务进程分离。采用 tcp 协议，内网部署。
调度进程负责管理资源（帐号，对方服务器的外网地址列表，代理列表，业务进程 ...)
业务进程只管获取资源和请求和解析并回传。

最终干赢其他对手，甚至于把金融网站打崩（调度里面的动态计算任务间隔，配置成 0 了）。
起到最大作用的原因并非代码层面。

==>价值 800 元的经验在这里<==
而是找到对方服务器所在机房，并且拿到了源服务器。请求相应时间从 200ms 下降到 40ms。