性能还好，我对比过 peewee 和 sqlalchemy 的性能都差不多。如果不存在锁或其他等待，速度一般卡在大批量数据插入时比较慢，sqlalchemy 有个 bulk_insert 的方法，不过大量时间会花在构建对象或 append 插入数据里面。但具体执行插入到插入完成这个阶段，到底是数据库是瓶颈，还是网络，还是对象的构建销毁比较耗资源，就没测过了。

@n3hatv2 pool 子进程没用过耶，pool 线程池就用过，还是 subprocessing ？ executor ？所以我猜你有两个担心的地方，一是 multiprocessing 这块可能共享，二是 threading 这边可能会共享。前者我一般用一个 docker 一个 process 所以不熟悉，不过据搜索结果看 multiproccessing.array 专门用于共享内存的，并用 actor 模型处理消息，所以我理解是不会共享的，所以这里我们是一样的，不用管。至于 threading 嘛，是会的，我也很常用 threading_pool.map 然后通道来传消息，还能共享变量。假如你的 Model 绑定了 session，在使用 Model 时，session 在 commit 的时候会把所有都包含进来……所以每个线程应该单独使用 session 来完成。比如这样：

```
# 用调用函数的方式加括号()，一种明确的信号来建立连接
with session_scope() as session:
do_something()
```
不过我觉得更好的方法是用 Queue （线程安全的），集中处理所有的存储步骤。pool.map(worker_lambda, args)来执行任务，在 def worker_lambda 里面处理好后结果 push 到 Queue 里面：queue.push(result)，然后做一个 while True 的消费者，从 queue 取出结果，然后 session.add(result)来保存结果，result 包含多个结果，单独塞 X, Y, Z 变量也可以，但是多线程下顺序有可能会乱，所以有多个结果就一起塞。设置 timeout/retry/queue.empty 作为超时 /重试 /中止信号。这样就不用担心这种问题了，虽然每个自己处理也可以，但是我觉得那样会增加许多脑资源消耗，而且更容易出错和更难维护，其他人接手修改也容易出现 bug。不然你可以用协程，最后看看数据库的锁默认设置。最后最好避免全局变量这种东西，以后会搞坏自己。

flask-sqlalchemy 那个我不大记得，我记得是最后 db.session.commit()就提交了，或者有的人直接 auto_commit。这在多线程里面的确会有问题。如有错，请指出。

@n3hatv2 #2 Yeah~我还没遇到过进程不安全的问题！那我想请教一下大概原理，或有链接分享一下吗？是多进程，多线程还是协程下不安全，竞态？还是别的原因？我现在有很多和别人一起写的用到 flask-sqlalchemy 项目是在 docker 集群上跑的，web 服务层有的也用到，新的才是纯 sqlalchemy，想了解一下。

这里没有写清楚是 flask-sqlalchemy 还是 sqlalchemy。flask-sqlalchemy 的文档写的是 Model.query，它会返回一个 BaseQuery 的类，继承 sqlalchemy 的 Query 类，实现了一些额外的东西，比如 paginate 的方法。但看看上面方法 2 就知道，Model 和 session 一点关系都没有，这是因为在 app 里面封装了，不然 session.commit()怎么会知道上面那个 Model 做了什么。这也造成，当你只想使用 sqlalchemy 而不是 flask app 时，你会发现用不了，因为没有共享上下文，因此在调试和写测试时耦合度会比较高，那些喜欢自己写代码而不是学习一整套方案的人就不喜欢 flask-sqlalchemy 的，比如我。同时从代码看，sqlalchemy 的方案更加直接，session 可以简单理解成用于建立连接，session 传参去 query 模型，最后还要 add 一下加入事务，commit 提交，虽然代码多一点，但逻辑很清洗。而 class 只是映射 sql 逻辑成一个面向对象的 object，通过操作 object 来操作 sql。

session 是抽象出来的概念，实质关键是用来处理链接问题。建议用 sqlalcehmy 而不是 flask-sqlalchemy，因为解耦方便，组件化复用也可行，而不是跟 flask 耦合在一起。sqlalchemy 可以用 session_scope，create_engine 自己写个连接方法来处理，虽然入手肯定是没 flask-sqlalchemy 那么方便，但也是一次编写多几行代码，终身使用了。另外 peewee 是没有处理这个问题的，看起来更简单但不懂用埋了坑。peewee 和 flask-sqlalchemy 一样，也是 Model.select 这种形式的，但没有自动关闭连接。因此，对于长期运行的任务，队列等，某些数据库由于太长时间接受到请求就会直接中断，因此 peewee 在这种情况会出现 client 报错的原因，因为 timeout 了。peewee 的 issues 的官方给出解决方案竟然是 conn.close()这种东西，这在涉及 import/复杂业务容易出现单个 instance 里过早关闭的问题，感觉就像一不小心就变野指针，是个 bad design。

@shimomiaizo #25 原来如此，的确想想我们的整体设计水平是在人家之下。定居那个不重要，其实我怕定居这种玩意，我只想出去找一下工作机会，如果有的话，我是单纯喜欢到处跑接触不同东西的。虽说我现在做后端这一块，现在已经是我第二个领域了。不过哪怕还年轻，不过去念书拿学位代价的确太高了，考虑到放弃目前工作腾空几年，将丧失目前职位这几年可能是最快的发展阶段，可能念完了设计从 0 开始，而在现在的领域也归 0 了。

我所在公司里面的设计屈指可数。不过我一般是把大部分产品当傻子看，哈哈……那些名牌大学硕士毕业出来做产品，画个流程图都乱七八糟，组织能力也不行，逻辑也不慎密，尤其在 IT 公司，在尝试结合科技和产品两个方面时，听那些负责产品的说话会感到非常尴尬，因为他们并不懂得技术，设计上缺乏实际得表达能力（出稿原型图，交互方面得组织），只有一张嘴，所以实际一个项目流程十分颠簸。而项目经理则通常是一个经验丰富，技术和管理都出色的人担任，所以通常出篓子都是设计，产品那边上游出问题。具体设计给我的印象是，非常忙，感觉就是很惨，通常做技术的 6 点多的就下班走人了，而设计还在不停地做。不过设计往前端发展其实也是条路，前端 + 设计 + 产品其实是一条路。而后端这边一般所谓全栈则是后端 + 前端，不过经验上觉得，设计 + 产品 配 前端 + 后端是最节省沟通成本的。

snapshot 技术不会耗费很多硬盘，第一次完整备份之后它只会保存增量部分。但秒级备份用的不是 snapshot，它用的是日志，通过还原点 + 日志方式恢复。参考数据库。这种技术存在很久了。如有错请指出。

@parkcg 学 AI 是个人兴趣还是工作？工作尽快找家第一梯队公司进入，现在已经开始落地了。设计嘛，你也看到，虽然看起来一片惨淡，但 AI 算法和工程两个层面裂缝很大，现在行业还没到弥补这个裂缝的时候，目前几乎每个客户都需要大量人力物力支撑才可以发挥出 AI 的威力。相比之下设计所见即所得。

@IvanID 谢谢分享，这够详细的。我身边也见过一些前端 X 设计的，也经常和产品打交道。我在想设计师往产品和前端扩展应该是很不错的方向，每次看到产品、设计和前端在各自指点江山经常搞得一团糟。产品不懂设计，拿 axure 画个丑陋的设计稿出来，然后告诉设计，你把它转换成设计吧。设计画好稿后，经常不是完整的图，而是不同组件都画一个，然后前端做出来后，产品说不是这种感觉，或者说还要让后端写个程序跑起来先看看。而且交互方案一般由产品出，然而实际上很多产品缺乏文档能力，也缺乏设计能力，结果出来效果很笨拙。那些懂设计能用工具快速表达自己观念，并且画出交互设计图的产品根本不会存在这种问题。哪怕那个产品沟通能力比较好，也常常会如此。

@learnshare @rabbbit 谢谢两位，你们的方法我都做个 demo 试一下，我惊讶地发现现在的绘画板是配纸的，然后直接录入电脑。

@learnshare 交互设计可能迟点，不过说到 => 排版 /布局 /颜色，这方面我打算是上教材或课程看。我的理解是设计出图，给前端，然后就轮到组件库部分了，不过代码部分不担心。Good，我有思路了，所以 1. 先看这方面的设计理论，2. 然后配合 rabbit 所说的设计软件 ，3. 最后是前端实现就能构成最小完整单元了。Thanks。

@rabbbit 是的，那就是属于 UI 设计。那绘画板买得有点鲁莽了，我先试试。谢谢这么仔细的回答。

@rabbbit 谢谢！公司 UI 也是拿 dribble 的，好像大家都在用它做自己的作品集，二次元貌似是 pixel 的比较多。我比较喜欢欧美类的，二次元不是我的菜，不过实用层面上，我想首要是拿来做设计。画板买了个影拓 PTH660KTF，已经再路上了。之前尝试过用铅笔和纸，发现笔的选择，纸的不同对画出来的效果影响太大了（德国那种忘了什么牌子蓝色的铅笔，纸是复印纸，但好像还有好多其他要求，自己画的效果不理想，也找不到人指点一下，所以就暂时搁置了），现在是直接入个画板先乱画一番。

@fiht #5 你好，我并不需要鸡血，需要的是建议。我的行动力一点都不差。可能你去找个迷茫的学生，说就是干，他们还会谢谢你，然而我不会。因为你除了第一点之外，其余都是都在 judge 我，下面再质问我，最后再来一个 wild guess，你是不是学生？我建议去学学现代礼仪课程。你有什么想法是你的自由，但我提个问题不是让你来点评我的。我的提问不欢迎你，不管你什么水平是设计菜鸟还是大师，一律 blocked。

@boa2005 #4 你是对的，所以我不打算如你所言那样切入设计。现在编程工作很轻松，而且自己写代码收入大概比设计高多了（如果我现在是做设计而不是程序员）。不过我相对于天天看论文研究算法，我还是对设计更感兴趣，或许人人都往机器学习和区块链跑，但身在其中，却倒觉得并不是那么有吸引力。

@2Go #3 Me too! 那种男性逻辑动物，女性感性得要死得刻板印象真要不得。

@govizlora 谢谢这么深入的思考和回答。

1.2.我拿起工具完全没有思路。我找过一些外国的教程看，看起来很浅显，一开始让你自由发挥去尝试用不用的方法和风格创作，跑遍各个应用领域，然后再深入到底是什么造成了差别，为什么效果不一样。然后会从线条各个细分方面深入该如何表现。手绘完全是个人意愿吧，设计之外我对绘画很感兴趣，同时对于设计也算一个基础。目前不急着等它吃饭，所以可以慢慢深入。
3.4.技能学会了，我是想探索一下使用场景。不过还没丧失理智，最好是跨界结合两者，想看一下有没有现有的方案。比如有些人会分享出国做程序员，有的人会分享自己做外包，有的人远程，或者有的人把自己的作品挂到素材网站上买，记得我第一个博客就是购买一个设计然后自己加代码改造的。这都是些现成的方案，如果没有，还需探索探索。
5. 这是一个有趣的方向，让我再想想。

@cfans1993 #1 Thanks，你的回答让我找到了相关的基础课。

感觉 UI 好乱，还弹自家广告 “你写书单，雨雀买单”

谢谢！ + 1