@iijboom 可以 老哥很清楚。那我转移动了，39 一个月送 1000m

@hemingcn 可能是他们搞混了单位。。正常不可能给这么多的，给 10m/s 上行已经是很满意了

@levenwindy
@RedisMasterNode 明白 谢谢 那不用测了直接转网移动了

@lirunext 没用 我电话花了 5 分钟跟他们确认，我已经录音了。我觉得这个东西还是装宽带的师傅才知道我在问什么。

另外联通每个月比移动贵 90

@qviqvi 那种是保修不到 1 年的教育优惠剩机。。

@zuisong 你这个估计开不了发票出来，官网买又超了一点点好像

@zhongjun96 binlog 同步到 clickhouse 或者 es 直接查询，相当于用双倍的空间分别支撑 OLTP 和 OLTP 查询，如果能接受较长延迟 /执行耗时，或者说有超大批量查询要求的话应该转移到离线数仓去。

@Famio @OutOfMemoryError 对了还有一个原因是因为有些 sharding 算法并不是简单的取余，也是因为业务的特殊原因，需要实现一些奇奇怪怪的内容进去，所以不能只依靠 partition

@thinkingbullet Nice to hear. 不管好不好用，可以了解一下，感谢~

@kiddingU resolver 只解决连不同 db 的问题吧，好像不是解决分表的问题的

@Famio
@OutOfMemoryError
有历史原因的 Partition 有些场景不让使用（不管它是否好用，但是出于某些原因确实是不能使用）

@EAFA0 嗯嗯是个方案，我们现在也在用这样的写法

@zhongjun96 一般有扫表的方案和异构存储 /离线数仓的方案；另外在决定分表之前也是需要考虑业务是否要频繁的批量查询，如果非常多批量操作的话，设计的时候要看能不能把分表依据和批量操作的依据结合起来，或者不用分表的方案实现

@Nooooobycat 也是个解决方案

@dobelee 在理

@dobelee 我们也是这么做的，确实稳健，所有的流程都能在 debug 的时候看清楚，其实就是相当于嵌入业务了，能感知到，坏处在于多加几行代码，库表越多，写得越多

一加 6 LineageOS 用户路过，后面 LineageOS 不支持了吗？用着体验挺好的，我喜欢极致的轻量，最好什么应用都不要有哈哈哈，一加是这么多年的最佳选择

@huigeer 除了待遇还会有其他的因素影响是否要继续下去

@gunitunit
1. 面试不通过的原因自然是不得而知，很大程度会是答得不让面试官满意吧，可以是深度不够，也可以是广度不够，这些不重要。
2. 通俗来说怎么向别人更好地介绍你接触的业务，同时让别人有可以入手提问的角度。譬如如果你做了一个收款打款（业务表述）的东西，那换个话术讲它可能是一套数据强一致的 CRUD （技术表述）；又譬如我做了一个短网址服务（业务），那它本质上是一个流量入口，是一个承载 xx QPS 的业务网关（这个描述可能不太合适，但总会有合适的模型能套在你的业务上），它该具有 xx QPS 服务应该有的什么特点（例如可用性、性能、限流熔断 bla bla ）。工作得越久，业务越复杂，越应该想办法让它能在数十秒内让别人听明白（哪怕有一些偏差，也远胜于摸不着头脑）。