频繁写入数据且需要做计算， Go/Node.js/Ruby/C#/ Python 哪种更合适？

直接 SQL 不行吗，merge

@kxjhlele 需要做计算，要对历史数据做各种计算

这种情况下瓶颈不是在数据库么？
要选的话就 go 呗，可以支撑很大的并发，只要数据库能抗住

维护一个内存变量，存这 500 条数据应该占不了太多内存。真要落盘，那就多块 ssd

SQL 数据库有个内存表，好像没有锁的问题，可以考虑拿来做中转罗盘

@keepeye 讲道理不会在数据库，统一读取之后，然后锁住用户，更新数据再统一插入。不过这样的方式内存占用肯定是多的了，而且如果是分布式的话，锁住用户也比较麻烦，可能需要维护一个公共锁。

我也觉得可以用 sql 做计算

@refresh #6 为啥会锁住用户，合理的做法应该是分两步，每步都是可重入的，过去 500 条这只是个缓存问题，语言无所谓吧

@ericls #7 逻辑放在 sql 里面后期维护要崩溃的

@ericls sql 做计算比较难吧，每条数据的计算方法可能是不一样的，当然也可用存储过程来解决，不过这个存储过程可能会相当复杂

@sujin190 肯定要锁用户的，不然上一次计算还没有完成，下次用户又提交一笔就完了。
@Xbluer 是的

@refresh #10 难道不是基于用户提交的过去 500 条数据计算么，还有基于计算后的 500 条历史记录再计算的？啥场景这么奇怪的需求

@sujin190 用户可能只修改一条数据，但是有可能因为用户提交的其中一条数据，而需要修改所有的记录。举个例子，假如我现在有一个记帐系统，为用户提供两个功能：1. 每笔帐会有一个余额； 2. 会告诉用户总资产的变化。

那么每笔记录就需要做两个事情：1. 计算余额； 2. 计算总资产的变化。如果改动了中间一笔，那么后面的余额都会发生变化，且每天的总资产也会发生变化。

@refresh #12 你举这个例子很不恰当，完全不符合现实情况，从现实来说，交易流水完全基于现实动作在时间维度产生，因为时间不可逆转，所以使资产或者余额发生变化的交易流水同样不可能存在需要修改的情况

如果因为某些情况之前的交易存在歧义或者错误而发送交易纠纷解决，那么既然现实已经在新的时间维度上真实发生了一件交易纠正的行为，那么就应该真实的产生一条新的交易记录从而使余额或者资产发生变更，修改原交易记录是极其不恰当而且也不符合现实的

关于系统异常导致的问题，下一条的交易变更应该完全基于上一条已提交完结的事务产生，在此种情况下不应该存在中间某条是错的情况

@sujin190 不是哦，交易流水确实不可改动。但如果是用户主动记账呢（例如像随手记这种），或者是一些仓库库存这种呢？