我们是音乐 DAW 厂商，在寻求音频信号处理与 Flutter 开发人才，细节可以查看我们的掘金专栏： https://juejin.cn/user/1997173786688888

不知道 LS 一段人在说什么。。。。。。。

这个东西叫做 类型断言。。。。。。，很多现代静态语言都有这个功能，比如 Rust 。

17 年毕业，到 19 年初，在当前月薪 7k 左右，可以存下 6W。 很厉害了

1. 现在不讨论，不代表不火热。哪个系统现在多多少少没有用到 NoSQL 来做业务。计数器场景，中间结果传递等。你看现在有人谈论电灯吗？
2. 大家谈论的都是新事物，一旦稳定下来就没有八卦的意义。
3. 不同的技术有历史生命周期。
4. 任何新事物的诞生总有大惊小怪的标题党。

这不符合目前主流的 KV 数据库定义啊（ Key 一般都是一个 String ）。
所以，这个轮子就是自己造了。

====

自己设计一个 KV 数据库（ key 是一个 List ）。
这样才可以在语义上满足题目的需求。

AWS 实现了其他都没有实现的真正按量收费。
磁盘，贷款，流量，计算资源全部按量收费。不坑。

没看到这个和 html 的差异是啥。。。。

@xiamingchong 能够满足需求，但是有信息丢失，比如系统需要扩展一下功能：

在 URL 冲突的时候，我想获取下冲突时间，犹豫 artical:id 这个属性的信息丢失，没法方便的计算。

首先，你得有索引的概念。

通常的，在你的设计中， url 与 title 的概念其实对应的是数据库理论中的唯一键，我们都知道 MYSQL 要做到某个字段唯一，那么需要添加 unique index 索引。

redis 作为一个非完全的数据库，是没有完整的数据库理论中的这些概念，这就要求我们自己来实现。

redis 实现一个索引也是简单的。按照题主的需求，我们完全可以构建这样的索引：

artical:index:url:${url} id url 索引
artical:index:title:${title} id title 索引

aritical:index 为索引前缀
:url :title 为索引名
${url} ${title} 为索引值
id 对应 artical:id 的值

然后我们可以用 url > title 的优先级顺序来做索引查询。


在 redis 这个特例中，为了解决原子性的问题，我们需要使用 pipeline 模式来模拟事务。

@miao1007 那该换块屏幕了，我的屏幕可以显示 100 行+啊

首先，多余的函数调用会增加额外的 call 时间。除非可以做到零抽象。比如用宏来拆分业务，其实我是喜欢用宏来写代码生成器的。

如果，是 Web 应用，那么函数 call 时间之类的时间可以忽略，爱写多少层写多少层。毕竟撑死系统的都是烂 SQL 。


函数写的短小是政治正确的，然而并不具备多大的现实意义。我见过太多知名代码的函数太长了，一个 C 文件数万行代码的比比皆是。

这个问题，我们可以提炼一下。

1. 什么叫结束？

我们举个例子，对于手机来说，并不存在结束对话这个状态。只有接通，未接通，通话中，挂断等状态。因此，此时，手机网络无法获知与处理对话结束这个状态。那么，现实中，它是怎么工作的？

A ： 你好！
B ：你好！
A ：....
B ：.....
A ：先这样吧，下次再聊！（ A 尝试发起结束对话）
B ： Bye ！（ B 确认结束通话）

然后 A ， B 互相挂断电话。


同理， TCP 中并不存在所谓的数据接收完毕这种状态。因此，这种状态是我们人为附加上的，所以，需要我们人为的来处理这件事。

首先，我们来看看 HTTP 是怎么工作的。

在 Http 标准分为固定格式的 Header 与任意格式的 Body 构成。
在 header 中有定义 Content-Length 字段。

Http 的定义中，其实就包含了上述各位描述的：特定 chunk 符， DataLength 等技术手段。

首先是 Http Header

Http Header 就是一组固定格式的文本，内部通过特定符号完成断句。

从 Header 中读取到 Content-Length 字段，读取等长的 Body ，然后关闭 TCP 连接。

当 Content-Length 未读取成功的时候，则等待服务端断开连接。

我们在使用浏览器下载稍微大型的文件的时候，通常会遇到两种情况

1. 100KB/12.3M 预计 2 分钟后下载完毕
2. 已接收 100KB

原因，我们可以思考。

现在，我们再来看一个经典的 TCP 协议。 MYSQL 协议。

MYSQL 在 TCP 层，把数据封装成一个一个的 packet 。每个 packet 的信息非常少，我们可以粗略的理解为

|DataLegnth|DataBody|

读取每个 packet 的时候，首先读取 DataLength,接着读取 DataLength 长度的 DataBody.


综上所述。

在 TCP 中，数据传输必须要有一个协议。这个协议至少要有一个信息，就是定义一个完整数据的长度。

通常的，有两种通用的可选的解决方案。
一，任务执行完毕之后，由任务服务发起 notify 。通常的是使用 HTTP POST 的方式传递任务标识以及状态。用于 notify 的 URL 怎么传递，不在本问题范畴内。我们可以任务入队列的时候传递，也可以由任务服务统一配置。

二，任务成功压入队列之后，向任务提交方返回任务 id 。任务服务提供 query 接口来查询某个任务 id 的状态。

事实上，我们在实现队列服务的时候，两者可以一起实现，并不冲突。

在真实的实现时候，还会有更多的问题需要考虑。
1. notify 失败怎么办，是跳过还是重新 notify 一次？
2. 是否有可能 notify 成功了，但是 query 却还无法查询到数据？