@shyling

除了 GitHub Free 为个人帐户提供的功能外，GitHub Pro 还包括：

> 通过电子邮件提供的 GitHub Support
> 3,000 GitHub Actions 分钟
> 2GB GitHub Packages 存储空间
> 私有仓库中的高级工具和洞察力：
>>> 所需拉取请求审阅者数
>>> 多个拉取请求审阅者
>>> 受保护的分支
>>> 代码所有者
>>> 自动链接的参考
>>> GitHub Pages
>>> Wiki
>>> 仓库洞察图：脉冲、贡献者、流量、提交、代码频率、网络和复刻

https://docs.github.com/cn/get-started/learning-about-github/githubs-products#github-pro

在校生可以申请免费的 GitHub Pro

都可以，varchar 方便读，int 节约一点点空间，IP 应该不会有模糊查询的需求吧？
同一个项目中使用统一规范即可，不用纠结

可以商用，一般没什么问题，不要用原来的名字，最好不要用相似的名字，比如：Kafka -> Better Kafka ，他可能会生气

荔枝现在价格和官网差不多吧

加签和加密的使用场景是不一样的

MD5：例子中是为了防止报文被篡改，服务端拿到的报文会再生成一遍签名，和客户端传入的签名进行匹配，不匹配说明报文被中间人篡改了（或者是 bug ），就可以拒绝该请求。

RSA：私钥加签，公钥验签；公钥加密，私钥解密。
通常用于双方都有开发能力的场景，比如你想调用支付宝的 OpenAPI ，在注册商家时，会和你交换公钥，这样就可以安全的交互了。

打开 Chrome devtool ，把 Disable cache 勾上再试试

试试用 force index
或者 order by (id+0)

我想被裁

平时都用 https://search.maven.org/
详情页信息比较多 https://search.maven.org/artifact/io.netty/netty-all/4.1.82.Final/jar

没必要强行用数据库的思维来使用 es ，这只会让初学者更加困惑，index 就是表示一种（一类）东西，从字面意思去理解即可。


为什么删除 type 可以看官方的解释： https://github.com/elastic/elasticsearch/blob/6.5/docs/reference/mapping/removal_of_types.asciidoc


谷歌机翻：

为什么要删除映射类型？

最初，我们谈到索引类似于 SQL 数据库中的数据库，类型相当于表。

这是一个糟糕的类比，导致了错误的假设。在 SQL 数据库中，表是相互独立的。一个表中的列与另一个表中的同名列无关。对于映射类型中的字段，情况并非如此。

在 Elasticsearch 索引中，不同映射类型中具有相同名称的字段在内部由相同的 Lucene 字段支持。换句话说，使用上面的示例，用户类型中的 user_name 字段与 tweet 类型中的 user_name 字段存储在完全相同的字段中，并且两个 user_name 字段在两种类型中必须具有相同的映射（定义）。

例如，当您希望 delete 成为同一索引中一种类型的日期字段和另一种类型的布尔字段时，这可能会导致挫败感。

最重要的是，在同一索引中存储具有很少或没有共同字段的不同实体会导致数据稀疏并干扰 Lucene 有效压缩文档的能力。

由于这些原因，我们决定从 Elasticsearch 中删除映射类型的概念。

风险大于收益，涨幅高于 30%可以考虑

不接熟人的活，发生这种情况，有些人不好意思开口，有些吵了一架朋友关系破裂，很现实。
如果是不认识的客户，可以想说什么就说什么，不给钱就不给源码，甚至留点后门。

md 转 html 的开源项目太多了，docsify 之类的都已经很好用了，重复造这种轮子没什么意义，不如专注「写笔记」这件事本身。

如果是 html 转 md ，那倒是挺期待的。

有代码参考吗

秒杀的主要瓶颈在数据库，尤其是 MySQL 这种，所以目标是减少无效请求，保证请求到数据库层面的都是有效的，所以用缓存是必要的。


1. 客户端按钮设置隐式冷却

OP 描述的“提交信息后跳转到指定页面”，用户点提交按钮，可能会返回上一页，然后继续提交，这样会生成很多无效的订单，我抢消费券就是这么干的，所以需要加一个冷却时间，用户一直操作，实际上每秒可能只有一次请求

2. 网关层限流

按钮冷却只能防普通用户，网关限流用来防止懂技术的脚本哥，根据 IP 或者 UserId 进行限制请求次数。
或者直接对商品进行限流，例如：如果商品只有 10 个，每秒请求有 10000 个，那么实际上大部分请求都是无效的，允许每秒 100 - 1000 请求进来即可，其他的直接返回「已抢光」，这里可以使用「令牌桶」和「滑动窗口」算法。

3. 服务层

OP 说用 UUID ，我感觉还是后台生成比较好，收到请求后，生成一个 OrderId 放到缓存中，然后通过 MQ 异步创建订单，直接把 OrderId 返回给客户端，再提供一个接口让前端轮询缓存中的订单状态。
MQ 消费完成后更新缓存中的订单状态，客户端发现订单已创建，再去查询真正的订单详情。

服务层使用 Redis 维护库存数量的优点也很明显，如果库存没了直接返回即可，不用调数据库，保证数据库扣减库存、生成订单都是有效操作。

4. 数据库层

通过数据库自身的锁保证原子性，防止超卖，此时数据库基本没什么压力。

这是 xxl-job 的源码，字节就改了个名字而已

https://github.com/xuxueli/xxl-job/tree/master/xxl-job-core/src/main/java/com/xxl/job/core