@qq1004108488
那你要说清楚自己的目标，从帖子的标题和正文来看，读文档就是目标了
如果目标是考试，培训班可能会有很好的作用，找熟悉那个考试的人问问吧

https://golang.org/ref/spec#Channel_types

The capacity, in number of elements, sets the size of the buffer in the channel. If the capacity is zero or absent, the channel is unbuffered and communication succeeds only when both a sender and receiver are ready. Otherwise, the channel is buffered and communication succeeds without blocking if the buffer is not full (sends) or not empty (receives). A nil channel is never ready for communication.

communication succeeds 就是 case 可以运行

如果你的目标是读懂文档，需要做的事情大概是
1. 学懂高中英语，高中英语包含所有会用到的英语语法
2. 靠查单词和语法的方式读文档直到能读懂。视你的英语水平，可能很快也可能需要很久才能达到目标

这种事情不是靠报班学来的，原因有两个
1. 培训班通常有明确的目标，通过某个考试这一类的。培训的内容会非常针对这个目标，对总体的能力提升不大。比如你不太可能通过一个 Java 培训班学到很多 Computer Science 的知识。我不知道有专门教你读文档的培训班。
2. 学习这件事情主要是靠自己的，培训班的作用主要在于督促你把时间花在学习上。

select table1.date, to_json(table2)->table1.date as v from table1 cross join table2 order by 1;

需要再处理一下 date 转成 TEXT 类型

公司通常会要求体检，那你按照公司的要求去做就好了
如果公司没有问，书面的东西也没有要求你声明所有既往的疾病 ，那当然就没必要说
如果体检能过，那找到一份工作不是难事。即使体检过不了，也有不要求入职体检的公司

从公司的角度来说，并不是在乎你有没有得过什么病
而是如果一个员工得了重大疾病，就可以获得很长的带薪（有折扣）假且公司不能辞退
公司只是不想承担这个风险而已

这个事情和行业没关系，如果不是打算破产或者打算跑路的公司，通常都会考虑这个

这是国家规定带来的问题，把养病的责任推给公司，导致了病人失业

@darmau
BTC 的分叉相当于把原来的一家上市公司拆分成两家公司，如果你持有原来那一家公司的股票，拆分完你持有了两家公司的股票，这个拆分操作本身没有让你持有的东西减少。
拆出去的可能只是原先公司的一小部分，原先公司的股价仍然很高也完全正常。

央行发行货币大约是说一家公司本来有 100 股，你持有 2%，然后这家公司又增发了 100 股，增发的这个过程也没给你任何的好处，但是持有的公司股权就只剩下 1% 了

这完全是两回事

@vencent

> 而 go 语言的 len 函数对于其他内置类型来说获取的是容器的长度（即元素的个数），而对于 string 类型获取的却是字节数。这种奇怪的不一致我认为是它的设计问题。

对所有类型，len 返回的都是
总字节数 / sizeof(一个元素)
对字符串，一个元素指的是 byte，否则 sizeof(一个元素) 不是常数
这是它一致的地方

另一个 len 不返回 code point 数量的原因是，得到字符串里 code point 个数需要把整个字符串遍历一遍，这样会慢

另一方面，code point 的个数也不一定是你想要的结果，因为在某些情况下多个 code point 才对应一个字，你会不会想让 len 返回字的个数？


至于为什么 for _, char := range "string" 是用 code point 来遍历而不用 byte 来遍历
我觉得你不会希望用 byte 来遍历字符串的

@petelin

> 为什么要路由到同一台机器？

如果同一个用户的请求会被路由到不同的机器上，就需要一个中心的数据库来记录哪些用户发过请求，这个数据库会成为瓶颈

> 那台机器挂了呢 扩容了呢？

这里的点是按照用户的 id 来分请求，减少后面每一台机器上的负担
后面的“一台机器”可以不是一台机器，你改成若干台机器加 Redis， 是一样的
这个若干台机器加 Redis 的东西可以继续扩容，但是 load balancer 上的后端不能增加
另外楼主给定了请求数量的上限，在这个题目的范围里不需要考虑扩容

> 还有这个算法太简单了 可能抽不到 200w

能抽到多少数字和算法简不简单没有关系
如果你觉得不行，请直接指出来哪里有问题

1. 给登录用户一个 jwt，客户端在发的请求的一个 HTTP header 里带上用户 id
2. 在 load balancer 上，拿用户 id 来决定路由，让同一个用户的请求只会被路由到同一台机器上
3. 接到请求的机器验证 jwt，并且记下来发过请求的用户，如果这个用户已经发过请求就直接返回
4. 随机决定 1% 的用户中奖，然后把数据库上把剩余奖品的数量 atomic x--，如果 x>0 就给用户返回中奖了

数据库上只有 200 QPS 的请求，只要是支持 atomic 操作的数据库应该都能用
其它的部分互不依赖可以无限加机器

没做过类似的东西，大概想了一下这样应该能用

1. size_t 当然能用，用对了就是安全的，用错了可能不安全
2. 发代码要用复制粘贴功能，不要手动输入
3. 发代码要把代码粘全，你发的代码编译不过

@HangoX
这种库通常不会有 ECB 的，因为用 ECB 就已经写错了
类似这种的还有 libsodium

@no1xsyzy
请去学习一下关系型数据库的范式
在一个符合范式的数据库上做查询，一定会用一堆 JOIN

当然我没有说符合范式的数据库适合用在所有的地方

@CUMTProgrammer
这是一个常见的话题，早就有很多讨论了

MySQL 的 planner 基本上只能处理简单的 SQL，稍微复杂一点的 SQL 就崩了，所以通常的建议是只写简单的 SQL
3 这个数字没什么神奇的，想一下也知道 3 是个随便定的数
另外，Java 规范凭啥要定 SQL 该怎么写，是不是在阿里巴巴写 C 代码就可以随便 JOIN 了

如果需要保证的是每个表上的操作都是 O(log(n)) 的查询，至于用不用 JOIN 根本不重要

你可以直接忽略掉这一条，直接 JOIN 就好了，没什么不行的
不过，你需要知道自己写的 SQL 到底做了什么；或者如果你不用 JOIN，你也需要知道自己的多次查询再合并到底做了什么

如果你用的数据库不是 SQLite 或者 MySQL 这一类的，那么 JOIN 通常会更快

这种事情只有测试过才能知道

优先级会影响内核在调度时的选择，操作系统当然会尽力把 CPU 分给优先级高的进程，但普通的操作系统不能精准地把 CPU 恰好分给优先级最高的进程

另外当然还存在各种各样其它的影响

把 PostgreSQL 的文档里关于 SQL 的部分全看一遍，然后去拿 SQL 写各种本来不该拿 SQL 写的东西

比如 https://github.com/crvv/sql/blob/master/brainfuck/interpreter.sql

如果一个数据库 instance 搞不定所有的读写请求，那么你可以使用多个 instance 来搞
有不同的方案来使用多个 instance，读写分离是其中的一个
或者说你也不一样要完全读写分离，只要把一部分读请求分走，也许就能好了

> 如果是异步同步，可以保证写主库成功之后返回，但保证不了延迟。比如写完马上读就会有问题

是会有问题，但有的业务可以接受有这个问题，或者用另外的手段处理这个问题。
或者你可以只把不需要强一致性的读请求分走。

> 如果等待同步从库成功后再返回，实际就是双写。那么故障几率就更大了，可用性就会降低

出故障的概率会变大，但是数据出错的概率会变小。某些情况下可以接受系统挂掉但是不能接受丢数据。

而且这么干的前提是你用一个 instance 搞不定，搞不定的事情就没有可用性，现在能搞定了才有了可用性。
这里不应该说可用性降低了。