Tag: sub

PostgreSQL 的 Job Queue、Application Lock 以及 Pub/Sub

Hacker News Daily 上看到一篇講 PostgreSQL 做 Job Queue、Application Lock 以及 Pub/Sub 的方法：「Do You Really Need Redis? How to Get Away with Just PostgreSQL」，對應的討論在「Do you really need Redis? How to get away with just PostgreSQL (atomicobject.com)」這邊可以翻到。

拿 PostgreSQL 跑這些東西的確有點浪費，不過如果是自己的專案，不想要把 infrastructure 搞的太複雜的話，倒是還不錯。

首先是 Job Queue 的部份，從他的範例看起來他是在做 async job queue (不用等回傳值的)，這讓我想到很久前寫的 queue service (應該是 2007 年與 2012 年都寫過一次)，不過我是用 MySQL 當作後端，要想辦法降低 InnoDB 的 lock 特性。

async job queue 設計起來其實很多奇怪的眉角，主要就是在怎麼處理失敗的狀態。大多數的需求可以放到兩個種類，最常見用的是 at-least-once，保證最少跑一次，大多數從設計上有設計成 idempotence 的都可以往這類丟，像是報表類的 (重複再跑一次昨天的報表是 OK 的)，另外每天更新會員狀態也可以放在這邊。

另外少見一點的是 at-most-once 與 exactly-once，最多只跑一次與只跑一次，通常用在不是 idempotence 的操作上，像是扣款之類的，這邊的機制通常都會跟商業邏輯有關，反正不太好處理...

第二個是 Application Lock，跨機器時的 lock 機制，量沒有很大時拿 PostgreSQL 跑還行，再大就要另外想辦法了，馬上想到的是 ZooKeeper，但近年設計的系統應該更偏向用 etcd 與 Consul 了...

最後提到的 Pub/Sub，一樣是在量大的時候拿 PostgreSQL 跑還行，更大的時候就要拿 Kafka 這種專門為了效能而設計出來的軟體出來用...

Amazon SNS 也支援 FIFO 模式了

看到 Amazon SNS 也支援 FIFO 模式了：「Introducing Amazon SNS FIFO – First-In-First-Out Pub/Sub Messaging」。

Amazon SQS 在 2016 年就已經先支援了：「Amazon SQS 支援 FIFO 了」，官方的文件可以在「Amazon SQS FIFO (First-In-First-Out) queues」這邊翻到。

在使用 FIFO mode 時與 SQS 有一樣的速度限制，每個 topic 只能到 300 TPS：

You can use SNS FIFO topics in all commercial regions. You can process up to 300 transactions per second (TPS) per FIFO topic or FIFO queue. With SNS, you pay only for what you use, you can find more information in the pricing page.

不過之前有需要保持順序的應用應該都先用 SQS workaround 了，不然就是自己搞能夠 FIFO 的 pub/sub 架構了。

Let's Encrypt 從七月開始將會改用自己的 Root 簽發憑證

Let's Encrypt 宣佈了以後的憑證的簽發計畫：「Transitioning to ISRG's Root」。

主要的改變是 2019/07/08 之後提供的 intermediate CA 會改變，從現在的 cross-sign 變成只有自己的 Root CA：

On July 8, 2019, we will change the default intermediate certificate we provide via ACME. Most subscribers don’t need to do anything. Subscribers who support very old TLS/SSL clients may want to manually configure the older intermediate to increase backwards compatibility.

目前的簽發用的兩個中介憑證 (Let's Encrypt Authority X3 與 Let's Encrypt Authority X4) 是由 Let's Encrypt 自己的 ISRG Root X1 與 IdenTrust 的 DST Root CA X3 所 共同簽署的：

這是因為 IdenTrust 的 DST Root CA X3 憑證很久前就被各家瀏覽器信任 (像是 Mozilla 的「Request to add two additional IdenTrust root CA certificates」這篇，可以看到 2007 年就被放進去了)，而 Let's Encrypt 當時為了更快把可用的產品推出，所以跟 IdenTrust 合作，採用 cross sign 的方式讓 Let's Encrypt 簽出來的憑證被一般瀏覽器與函式庫所信任。

現在差不多過了三年半，Let's Encrypt 成為目前世界上最大的 SSL Certificate 發放單位，加上自己的 Root CA (ISRG Root X1) 也都差不多被整合進各家系統內了，所以打算要獨立自己簽了。

不過系統上可以設定，使用者如果有遇到相容性問題 (太舊的系統可能還是不包含 Let's Encrypt 自家的 ISRG Root X1)，還是可以設定使用有 cross-sign 的版本 (維持現狀)。與 IdenTrust 的 cross-sign 會維持到 2021 年九月，大約再兩年多一些：

Our current cross-signature from IdenTrust expires on March 17, 2021. The IdenTrust root that we are cross-signed from expires on September 30, 2021. Within the next year we will obtain a new cross-signature that is valid until September 29, 2021. This means that our subscribers will have the option to manually configure a certificate chain that uses IdenTrust until September 29, 2021.

對於自用來說應該沒什麼大影響，主要是企業用戶要注意相容性...

Small Characteristic DLP (Discrete Log Problem) 被解決

最近幾天在密碼學領域還蠻紅的話題 (雖然預印本在去年就發了)，EUROCRYPT 2014 上發表對 DLP (Discrete Log Problem) 的重大進展。

論文在 arXiv 上可以取得：「A quasi-polynomial algorithm for discrete logarithm in finite fields of small characteristic」。

針對使用小特徵值的有限域 (finite field) 的 DLP 問題 (也就是 Zqk 上) 直接從 sub-exponential 降到 nO(logn) (quasi-polynomial)。最常見到的應該是 Z2n。

雖然現有被廣泛使用的密碼系統在使用 DLP 建構時都是用 Zp，但這次的成果絕對寫下了 DLP cryptoanalysis 上的里程碑...