薛定谔的猫

实验描述如下：

把一只猫关在一个封闭的铁容器里面，并且装置以下仪器（注意必须确保这仪器不被容器中的猫直接干扰）：在一台盖革计数器内置入极少量放射性物质，在一小时内，这个放射性物质至少有一个原子衰变的概率为50%，它没有任何原子衰变的概率也同样为50%；假若衰变事件发生了，则盖革计数管会放电，通过继电器启动一个榔头，榔头会打破装有氰化氢的烧瓶。经过一小时以后，假若没有发生衰变事件，则猫仍旧存活；否则发生衰变，这套机构被触发，氰化氢挥发，导致猫随即死亡。用以描述整个事件的波函数竟然表达出了活猫与死猫各半纠合在一起的状态。

该实验的核心思想：

1、封闭容器中的猫，50%几率会死亡，50%几率会存活
2、只有打开容器，才能知道猫的状态。也就是说，猫的状态取决于观察者（你）

生活中的薛定谔

讲讲我最近的一个真实经历吧：
最近做了个项目，主要由我来负责。大致需要我做的是：
提供一个接口，该接口功能如下：接受一串入参-->将入参带入模型-->记录入参、时间等参数至数据库-->将模型结果返回。
由于接口功能不算复杂，且给予的时间并不是很多，我选了使用python+flask+sqlalchemy+mysql的项目构架。

顺利地完成开发并部署后，一切貌似都进行得很顺利。
直到有一天，小伙伴跟我说，你这个项目，经常会出现一个现象：
“同样的入参，第一次访问会返回错误，下一次和后面几次就正常返回，过段时间后又会返回错误。”
既然是这样的描述，那我就看看日志记录呗。结果一看：

大致的错误是：MySQL server has gone away

每次接口的访问错误，都是这个。

mysql server has gone away

欧，好吧，看来是sql_alchemy的锅。有问题，那我们就着手解决问题吧。
感谢谷歌大大的帮助。我找到了如下答案和sqlalchemy官方给出的解决方案：

# sqlalchemy 1.2
engine = create_engine("mysql+pymysql://user:pw@host/db", pool_pre_ping=True)

# before sqlalchemy 1.2
from sqlalchemy import exc
from sqlalchemy import event
from sqlalchemy import select

some_engine = create_engine(...)

@event.listens_for(some_engine, "engine_connect")
def ping_connection(connection, branch):
    if branch:
        # "branch" refers to a sub-connection of a connection,
        # we don't want to bother pinging on these.
        return

    # turn off "close with result".  This flag is only used with
    # "connectionless" execution, otherwise will be False in any case
    save_should_close_with_result = connection.should_close_with_result
    connection.should_close_with_result = False

    try:
        # run a SELECT 1.   use a core select() so that
        # the SELECT of a scalar value without a table is
        # appropriately formatted for the backend
        connection.scalar(select([1]))
    except exc.DBAPIError as err:
        # catch SQLAlchemy's DBAPIError, which is a wrapper
        # for the DBAPI's exception.  It includes a .connection_invalidated
        # attribute which specifies if this connection is a "disconnect"
        # condition, which is based on inspection of the original exception
        # by the dialect in use.
        if err.connection_invalidated:
            # run the same SELECT again - the connection will re-validate
            # itself and establish a new connection.  The disconnect detection
            # here also causes the whole connection pool to be invalidated
            # so that all stale connections are discarded.
            connection.scalar(select([1]))
        else:
            raise
    finally:
        # restore "close with result"
        connection.should_close_with_result = save_should_close_with_result

使用了官方给出的解决方案（在每次与数据库连接之前，检查一下连接可用性，如果失去了连接，就发送一个'Select 1'命令，重新建立连接）

大家看到这里，肯定都不耐烦了吧😂
读者：作者你在干啥！！废话一大堆，还po代码，是不是为了凑字数啊！！💢💢
读者老爷！我写这么多（有点凑字数嫌疑🤫），肯定是有目的的。不要急哈～
读者：不要糊弄我！😠

修改并部署了以后，确实一切正常了，而且很长一段时间内，没有任何错误返回。但是，虽然一直没有错误，但是，问题来了：你没有办法证明，这个接口一直是好的呀，也许99次访问是好的，谁知道第100次是不是好的，第1000次，第10000次呢......
我的小伙伴笑称：这简直是“薛定谔的正确性”啊。（请允许我杜撰一下这个概念）