应用市场安装app异常排查

应用市场安装app异常排查

1，修改表结构，导致死锁

由上图死锁导致整个流程卡住，安装app的流程无法继续，导致应用市场安装app异常。

2，调用distribute安装接口异常

调用distribute接口异常，导致应用市场安装app失败，但是应用市场已经对数据库表、redis元模型数据更新，并没有回滚，导致数据不一致。

3，应用市场安装app异常

与场景2类似，应用市场本身的安装app接口异常，也没有回滚数据，导致数据不一致。

解决方案

1，业务制定回滚流程

应用市场安装app异常后，业务制定回滚流程，回滚数据库表、redis元模型数据等。
数据库在死锁后可以使死锁事务全部回滚，比如mysql可以配置innodb_rollback_on_timeout参数。 一个成熟的数据库产品肯定是满足事务的ACID的.

2，手动卸载并重新安装app

如果应用市场安装app异常，可以手动卸载已经安装的app，并重新安装。 distribute暴露的安装和卸载接口是幂等的，可以多次调用。

对于死锁（数据库锁表、分布式死锁等）情况，需要业务制定死锁处理流程，比如手动kill死锁的sql语句，或者重启应用市场服务等。

3，异步处理，最终一致性

大概就是参考k8s如何启动一个pod的流程，具体还没想好怎么做 ૮(˶ᵔ ᵕ ᵔ˶)ა

任何一个系统都无法保证做一件事情一定成功，这是不可能的，但是任何一个系统必须保证做一件事情结果的一致性，要么成功，要么失败，这是确定性的。 我们常说的tcp协议是面向连接的可靠传输协议，但是tcp从来不保证一定传输成功，tcp只保证数据传输了就一定成功了，同时传输失败了就一定失败了，没有中间状态。 类似地，对于distributed的安装、卸载和更新接口，它底层是etcd，etcd也不保证一定成功，但是保证数据的地表最强的一致性，要么成功，要么失败。