[杭州滨江] 30K,13 薪招个会 GO 的 PHP 后端

[xiaoshouchen]

主要做二次元文创相关的，公司网站 m.huabbao.com

不说官话套话了，来个有大流量、高并发经验的后端开发

公司目前用 PHP 开发，打算往 go 上转型，希望你有相关的丰富经验

给我发简历，或者打电话都行

邮件：xiaozhen0801#hotmail.com

电话：[phone]

[php01]

建议上云函数，或者先试下 RoadRunner 顶一下看看效果

[mosfet]

转 JAVA 吧，杭州最不缺 JAVA 的

[yuandj]

可以考虑下基于 swoole 扩展的 hyperf 框架，8 成能满足你们的需求，比 fpm 性能高的不止一两点，同是 PHP，迁移起来也方便。但话又说回来，感觉 go 也很香，但前期感觉只是新语言图个新鲜，可能是自己羡慕你们有机会从 PHP 转 go 吧，可以扩展个人的技术栈。

[Rwing]

纯粹的业务型系统 go 并不是更适合的语言啊
要说更适合，我推荐 C# 🙂
各大性能测试可以看看

[yoshiyuki]

曾经建议过你们创始人一开始就用 go， 然而当时没有引起在意

[ccppgo]

@xiaoshouchen #34 , 传 array 这个问题, PHP 也有对象啊, 甚至可以强制强类型, 没有那么夸张吧

[ccppgo]

@Evilk 老哥问一下, 你的应用 FPM 跑多少进程, webman 跑多少 worker

[yoshiyuki]

@xiaoshouchen 你这个抽奖改成伪随机就行，参考微博抽奖的逻辑，有一部分用户，是注定抽不到这个奖的，在请求到达时就直接 return，并发压力自然小很多

[shoaly]

@ArJun 我也看了一眼他们网站, 貌似没看到什么访问量很大的页面, 隐约感觉是不是同行攻击造成的...

[xiaoshouchen]

@shoaly 看 APP 呀，功能都在 app 里，至于同行攻击，日志能看出来个大概的

[xiaoshouchen]

有人给我发了邮件，但是我回复被拒收了，我微信号就是手机，可以加我微信好友，谢谢大家的指导，但是无论什么方案，都需要有人实际去做，需求太多，进度太赶，需要招人来一起去解决。

[sadfQED2]

@dwlovelife 因为没人在乎这点资源，另外因为 10 多年的屎山代码太烂，能用 1000 台为什么要用十多台，出事故谁背锅

[yEhwG10ZJa83067x]

我想请教下，在原有的基础上你转为 go 后能确保这几十台机器就能抗下这个并发吗？怎么判断是语言并发限制了你们？真心求教

[jhdxr]

我来唱个反调，推荐 LZ 转。

从系统的角度来看，原来的实现上烂，如果想要给彻底重写找个借口，那就让语言 /框架背锅换一个，这是最省事的借口了
从个人角度来说，多掌握一门语言，或者至少去了解了解下思想，没坏处。


另外就 @xiaoshouchen 回帖里举的<del>抽奖</del>秒杀这个例子来说，只要你还在访问 RDBMS，换啥语言都没救。。。

[xiaoshouchen]

@jhdxr 大部分逻辑走的 redis 和消息队列，但是有一些东西产品强制要求实时性，比如抽到的奖品需要支持分解，那么返回的时候就要给到抽奖记录 ID，那我必须生成抽奖记录，才能保证奖品可以正常分解，不然分解就可能存在问题。此时必须操作数据库，其他的比如积分可以用缓存，扣减的记录走队列更新数据库，特殊奖品的发放（不支持分解的）可以走队列。

[jhdxr]

@xiaoshouchen 先把配合业务一起去优化逻辑这一个方案放一边。『返回的时候就要给到抽奖记录 ID 』在我看来并不代表操作一定要实时入库，例如找个能保证唯一的算法生成，或者直接预先生成缓存里取，持久化的事情异步做。你如果担心用户领完奖马上分解以至于你异步操作还没完成（这用户手速真快，或者你们机器是不是都拿去前面顶着了异步就没资源了），那就分解那也顺便改改代码，不要光从数据库查，缓存也看一眼啊。。。

[barbery]

高并发场景换 go 是正道

[halk]

@jswh #44 这个官网也太草台班子了，特别是 在线预览 这块

[alexkkaa]

如果是为了业务稳定不如直接上 java