上のバカなことは、ラック使っている場合でパフォーマンスを上げるために各ノードがシーケンスキャッシュを使うようにさせている場合に問題となる動作を想定していたようだ。あるノードが1を得た時に100までキャッシュする。別のノードが次にシーケンスを得ると101になる。この間に最初のノードの2回目の書き込みが発生しないと配送先は現在のシーケンスを101としてしまう。これ以降、最初のノードの書き込みの2〜99は無視されることになる。したがって、シーケンスキャッシュの分だけ現在のシーケンスからひいてやらなければ危ない。追記の追記:だめだめだ。最初のノードからの書き込みがずーと無いまま、2番目のノードが201まで書いてしまえば、シーケンスキャッシュ分の100を現在の配送先が得ているシーケンス(つまり201)からひいても、次の最初のノードの書き込み(シーケンス2)は得られないことになる。なり、それは無意味に限りなく近い。いうか、負荷は高まるばかりなり。シーケンス抜けを考慮するとギャップの先頭にマージンを持たせる必要もあるわけだし。あと、最初のノードがダウンしたら2〜99は永遠欠番になるわけだから、後の考慮がすべて無駄。SEQUENCEキャッシュを無効にするこの場合の負荷は?まんべんなく配送元の各ノードからの書き込みがあるならば、方法1に一工夫したバージョン。配送元の書き込みが基本的に単一ノードからだったり滅多に書き込みがなければ方法2。閾値をどう得るかはえいやの世界のような。すれば固く方法2が正解かも。追記:timestampを避けているのは半ば本能的なことなのだが、timestampでも良いかも。Oracleのタイムスタンプ関数を使った場合ラックだと必ず一致するのかな。そのあたりが落としどころのような。#再起動したら(前方向に)時刻がずれましたとかなるとやばめ(キーとするのだから重複したらすごくまずいというかそもそも書けない)だし。適当にplugin/disp_referrer.rbを以下のように修正。HPのノートVector(まだ迷っているっていうか、迷うだろう不要不急とは言えない状態では)。Amazonではそんなに投売り状態ではない。