@18889242351 #32 谢谢你的建议，我现在从 Adobe XD 和 Photoshop 学起，配合手绘板学速写联系快速出原型的能力。我写后端为主，不过业余主要是学习 Android 准备首先出一个设计简洁的 APP 看看样子怎样。

显卡不能看参数买, 而是看游戏在不同显卡下的评测买。根据实际经验, 在特效全开时, 你的定位在 2k 分辨率下保持 60 比较合适。因为 4k 下 1080Ti 在比如古墓丽影崛起这类游戏上都在 45 左右, 显存吃了 5g 左右, 那不是一张显卡能解决的了, 同时新电脑若 2k 下连特效都不能全开就不理想了。这几年的游戏要求硬件提升不多, 优化较差的古墓丽影崛起依然是很好的参照物。

另外内存太小了, 8g 会占掉 20%常驻, 这会在普通游戏下比较吃紧, 若是大型 RTS 游戏就会不足,那类游戏大量的单位会需要 16G 最好 32G 的内存, 比如说 Titan, 英雄连。

还有一个就是 CPU。CPU 对于大部分游戏都足够, 但是对于某些祖传单核游戏比如钢铁雄心等, 单核更强劲的 Intel 比较合适。玩这类游戏为主可以适当放低显卡要求提交内存和处理器。再说处理器不贵。

最后是硬盘。SSD 硬盘对于读条严重的游戏提升很大, 比如全面战争, 比如角色扮演, 这部分读条可能会产生超过 30 秒的时候会带来明显的体验下降, 尤其是那类剧情氛围类游戏, 生化奇兵很快, 但星球大战前线 2 就会加载非常久。

我建议把显卡提升到 2k60 的程度, 因为我用 1080Ti 因为 4k 不到 60 降到 2k 那么就存在性能过剩问题(价格也过剩)。其次内存 16G 是必须的, 还可以跳出游戏保持一些基本软件的运行。CPU 对特殊游戏有要求, SSD 不贵时入一个也很好用。假如有 PS4 还可以把你的 SSD 装到 PS4 不影响保修。

@shimomiaizo 我今晚看设计时 https://www.youtube.com/watch?v=CnfXJ2qjv5I 时看到 https://www.youtube.com/watch?v=m1diVY4Uzjc。Flutter，我不知道对于设计来说难不难，但我用了不到 1 个小时就写完了整个 demo 并运行在自己的 Android 手机上（我从未写过移动 app，毫无概念可言，只有后端基础） ： https://flutter.io/get-started/codelab/，移动端实际上体积更少，设计更多的 UX 设计，并且 Flutter 直接运行在 web/ios/android，我觉得你会感兴趣。相比于 swift/java 这些开发适合于个人项目（但这个很新，而且普遍做空这个框架，假如你要往前端发展还是学 Vue/React/Ng 之类吧，但单纯说个人项目，我觉得很好很好，相对于混乱的前端生态圈和学习成本）。

@n3hatv2 #9 我觉得你现在的方法很好了，那样做就完全不用考虑原先的问题了，walk round 同时也是一种风格更好的 design。Queue 模块放在 multiprocessing 虽然没问题但共享 Queue 比较麻烦，所以 Redis 更方便，就是多了个 Redis 依赖。

1.不会
2.是的，假如 session 是同一个，就会覆盖掉了。因为 Model.attr = 'xxx'时相当于塞进了预备被提交的 box 里面，commit 就全部提交了。假如相同 id，应该是原有 box 已有内容被覆盖了一遍（我猜，源码我就不看了= =）。

性能还好，我对比过 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，它用的是日志，通过还原点 + 日志方式恢复。参考数据库。这种技术存在很久了。如有错请指出。