日活 3K 左右的 app，后端有必要上 Java 吗？

@cnbattle 求头像原图

@vjnjc 已经到了加索引和缓存不能解决问题的地步了,服务器是分布式数据库集群,话说公司服务器是个大牛,给 freebsd 贡献代码的人,都是一开始数据库表设计不好,还有一个内部需要变更太频繁

你得知道性能瓶颈在哪才能优化啊…… 3k 的日活，能有啥瓶颈

这类型的后端，应该是以读为主吧，既然这样的话，如果性能瓶颈确实出在数据库上，直接上多个数据库副本，分摊一下查询请求，把眼下的问题先应付过去再说。然后再慢慢想办法重构也好，重做也罢，走人也行，看着办，哈哈

垃圾啊，日活 3k，关语言什么关系，素质不行明显

先把慢查询一个个找出来，改表结构、迁数据，加索引；再不行加 proxy 上 MySQL 集群；然后如果是读多，加一层 redis 缓存……但我感觉日活 3k …… emmmmm

说分布式 集群 缓存的好笑不好笑
3k 日活 1 核 1g 的服务器都稳稳的处理了 还需要那么多花样？

谈谈数据量吧 加了索引和缓存都还不行？

@woshipanghu 我说的只是 app 日活 pc 的也是在一起的,具体不详

@tomczhen 所以，对于已上线的项目。后期要整改的时候，也就是解决之前遗留的问题，没什么好办法了吗？

用 Node.js 吧，自学 3 小时后就可以了，日活 300k 都没问题

@cnbattle 我倒是感觉日活 3k 挺多的呀，对我们这种小公司来说

这个日活，随便写个 PHP 挂到应用云上不就行了。

@pynix 如果只是单纯显示，没有解析拆分的需求，那也可以吧。。。

@slgz 技术债务总是要还的，只是什么时候还，由谁来还的问题。并不是说不欠债就是好的，有时也会为了一些妥协而主动选择债务。

再说了，项目没到还债的时候就死掉的也是很多的。不管是主动选择还是被动，债务只要可控就是可以接受的——大不了离职嘛 ¯\_(ツ)_/¯。

通常说的解决方案就是重构，不过出于自身利益风险考虑我觉得更多人都喜欢重写——毕竟就算是一坨屎也是自己的香一些。

我只是一个负责背锅的运维，代码重构的经验还是让开发来传授吧，毕竟他们经验比较多 :doge:

是来搞笑的吧，3000 日活太小了 几乎就是九牛一毛 忽略不计

@cnbattle 3000 日活的 app 还有缓存的分布式数据库集群。。。。。。。。你这三千人是每秒操作一百次以上录入 50 条以上数据的机器人吗？(￣へ￣)

go、ruby 五年经验的可以当十年用，php 五年的你就当两年用，这样就不会出问题了，真不是看不起这个语言，而是 php 用的公司太多了，大量的低端外包公司都用他，你根本不知道他是不是做了五年的建站。

和 php 有毛关系。。。90%都是代码问题，如果真是 php 有问题。。那么 baidu，facebook 什么的还用 php 干嘛？