邯郸公司做系统对接，中间库不能当垃圾场
前几天邯郸一家软件公司来问，系统对接为什么非要加个中间库？先说结论：加了是为了缓冲，不是为了堆数据。两边节奏不一样，中间库能让它们各跑各的。但如果只往里写不清，它很快就会变成垃圾场。
中间库的作用是解耦
两套系统直接互调，一方升级另一方就得跟着停。加一层中间库，两边只面对它，升级就能各自安排。对方系统半夜维护，你这边的数据先落进去，等它恢复了再推过去。磁县有家公司就是靠这一层，避开了对方系统每周一次的大维护。多一层，换来的是互不打扰。
这套东西还有个好处是能重放。同步没成功的数据留在里面，修好之后重新推一次就行。没有这一层，数据只能靠人工补，很容易补漏。在实施阶段，我会保留 7 天的原始报文，方便对不上时回查。邯山区一家企业靠重放机制补回过一批漏单。能重来，心里就不慌。
表结构要照着用途设计
中间库的表不用做得像业务库那么复杂。一般只要 3 类表：待处理、已处理、退回队列。字段上留好业务主键、来源系统、时间戳，够用就行。有人喜欢把对方的全字段照搬过来，结果字段一多，改起来牵一发动全身。临漳有家门店精简过一次中间表，维护量立刻降下来。按用途设计，别照抄。
退回队列必须留原因。只记一句没同步上没用，要写清是网络问题还是字段校验没过。原因分类清楚，后面统计才知道该改哪一块。上手之后，我给客户的交付里会附一份原因对照表。丛台区那边有家商户照这张表排查，发现多数问题集中在同一个字段上。原因写细，问题就好找。
临时数据要定期清
中间库最容易失控的地方是数据只进不出。处理完的记录要定期归档或清掉，别都堆在主表里。建议按时间分区，保留 30-90 天。我见过一个库跑了两年没清理，单表几千万行，同步越跑越慢。复兴区一家工厂清理之后，同步耗时降了一半多。定期清，是运维的基本功。
常见问题
中间库要不要做数据校验
建议做。校验放在写入前，能挡住大部分脏数据，比事后排查省事。
中间库要用什么数据库
普通关系型数据库就够。数据量大再考虑分区，不必一上来就上复杂的方案。
同步失败会丢数据吗
只要失败记录留在中间库就不会丢。关键是失败队列要有人看，不能只记不管。
邯郸的公司搭中间库，先想清楚它要解决什么问题，再定表结构。它不是数据仓库，用完就该清。说说要接的系统和每天的数据量，我就能判断个七七八八。你要是想听实话，信服无限邯郸会先帮你判断这件事该不该做。