「COMPANY」人力资源系统的后台批处理故事-番外篇

在中国人事系统”COMPANY”的批处理的背后，有一个暗中记录的補充说明。由于它并非正式的最新规范说明，只能作为一个参考，以便了解曾经存在过这样的时代。

队伍会从哪里来呢？

“公司”人事系统的批处理背后的事情
所谓”队列管理服务”。队列字面上就是Queue，但是它是如何管理顺序的呢？除了在Java内部之外，还准备了另一个投放口。它被临时称为”队列接收表”，以与下层兼容。

//「キュー受付テーブル」にレコードが入る。
//　　　↓
//「キュー管理スレッド」がそれを検知。
//　　　↓
//　ジョブ処理待ちへ

用于将记录添加到“队列接收表”的函数是“惯例”，这在本身只是一个批处理机制的内部讨论中。

//　★投入関数で呪文をとなえる（いくつか呪文には種類がある）
//　　　↓
//「キュー受付テーブル」にレコードが入る。
//　　　↓
//「キュー管理スレッド」がそれを検知。
//　　　↓
//　ジョブ処理待ちへ

现在，假设这是规格，那么希望使用这个“批处理”功能的使用者（各种产品和子系统）会采取什么操作呢？

例外之一

我正在自己构建一个（对用户来说）感觉不错的替代（使用者）的插入函数。

我正在制作。不知道为什么会这样，但是它是自己制作的。我认为提供的功能函数似乎不足。尽管如此，它仍然能够运行，历史是深奥的。

例外之二。

将记录插入“队列受理台”中。

无论如何隐藏函数，由于表格是公开的，所以只有在理解了其规范并加以精心设计的技巧才能达到目标。

康威定律

康威定律

无论是软件的哪个部分，都反映了创造它的组织结构。

是一个开放的组织。

最初的排队系统是什么？

以消息代理作为单一故障点——Ciaran O’Donnell的博客

队列系统是什么？
消息队列（MQ）是什么 – 简明易懂的解释 – IT术语词典 e-Words

消息队列是一个按照先进先出（FIFO，先入先出）方式进行消息发送的队列结构，它可以保存多个消息，按照被写入的先后顺序进行读取。当消息传递完成后，会被删除，以准备下一条消息的发送和接收。

经纪人是一种称为中介的角色，有两种队列系统，一种是没有经纪人的队列系统，另一种是有经纪人的队列系统。没有经纪人的情况下，当有请求时，立即对请求进行响应；而有经纪人的情况下，会接受任务，并在后台调度服务器进行处理，然后返回根据调度而执行的操作。

没有经纪人的话，可以立即回复，但是由于任务没有保存，如果有任何情况发生，处理就无法完成。相反，如果有经纪人，虽然处理需要花费时间，但是任务被保存，即使有情况发生，也能将处理执行到最后。

ZOZOTOWN引入的分布式排队系统-从产品准备到生产就绪-ZOZO TECH BLOG
Amazon SQS（用于无服务器应用程序的消息队列服务）| AWS
Amazon Kinesis数据流（收集用于实时分析的大规模数据）| AWS
队列存储| 微软Azure
事件中心-实时数据摄取| 微软Azure

如果是开源的话

卡夫卡 (Kǎ fū kǎ)

Apache Kafka 入门指南 – Qiita

Rabbitmq 兔形信鸽

芹菜

Nsq

还有很多学习的余地…
希望大家在假日里悠闲地享受这个小故事。