@randyzhao #9 　哦，我看你８楼说找到个接口，以为你表示就找到了。

@randyzhao 你没认真看帖子，楼主说的是人家搞定了虚拟电话后面的真实号码，虚拟电话没意义，需要基于 58app 来，而且打拨一次就换了。

@Philippa
假设我有表
class MfAdmin(Base):
id =xxx
....

我是在主进程里初始化 flask-sqlalchemy 的 db, db = SQLAlchemy(app) ,然后在主进程里以 MfAdmin.query 方式查出一组 user_list，然后将 user_list 以 pool.map()的方式（ multiprocessing.Pool 创建进程池）在子进程里对不同的 user(MfAdmin 的 id 不一样)进行并发处理，这里有几个疑问：
1. 如果 pool.map （）产生的不同子进程里处理相同 id 的 user，是不是会被共享？从你的回答来看，不会共享。
2. 如果 pool.map （）产生的不同子进程里,其中一个子进程执行 session.commit() ,其他子进程里修改的对象会不会被 commit ?
出于以上担心，我现在的做法是，属于同一个 db = SQLAlchemy(app)的主进程以及通过 pool.map 产生的所有子进程都只做读操作，如果要修改，扔到 redis 的 list 里，由独立的 db = SQLAlchemy(app) 进行同步的修改。

@Philippa @neoblackcap 我的模型有点复杂，是在初始化 flask app 的主进程里，通过 multiprocessing.Process 启了很多子进程，每个子进程会 query 出对象，然后还需要通过动态 pool.map 再传递到子子进程里做并发处理，遇到了数据库的值不符合预期，我担心 flask-sqlalchemy 这种全局 session 在不同进程里 query 的对象会被共享，进而导致互串；没有明确的证据，我对 Python 生态的 orm 也不太熟悉，目前的想法是改用原生的 sqlalchemy （非 flask 扩展），然后在每个子进程里创建 session,进程退出时 close，保证每个进程里的 query 对象是唯一的实例。

那么，我想请教下频繁 db_session = Session() db_session.close() 这个开销对性能的影响大不大？对于我这种场景正确的姿势是什么？我的担心是否是多余的？

@Philippa 感谢解答，我确实没讲清楚是 flask-sqlalchemy 还是 sqlalchemy，我正式因为在 flask-sqlalchemy 里遇到了进程不安全的问题想改成 sqlalchemy，每个进程独立的 session ；然后在查文档的时候发现 sqlalchemy 也有直接基于对象 query 的写法，比如 https://gist.github.com/podhmo/4345741，不过这个例子能看出对象 query 本质上就是 session.query()，通过“ query = DBSession.query_property()” 做了关联。。。

锤子的欢喜云不支持导出通讯录，买的坚果手机坏了后都无法导出通讯录，从此终生黑！