@daoqiongsi1101 #42
这个确实存在，和 C++框架对比性能相差更厉害。
问题是现实业务中，有多少业务能达到压测时的量，且外网带宽能支撑到这么大的量？

大厂不缺钱没有这方面顾虑，所以他们可以根据本地压测来选择性能更高的语言进行开发。

@XTTX #44
其实吧，一句大实话，哪怕外包做的再好，只要客户是没运营经验的，基本不出 1 年都会倒闭。
而如果有运营经验的，我认为自建队伍或招募技术合伙的做法，比找外包靠谱得多....

@XTTX #7
>有经验的外包公司绝对不会跟你“工程师思维”， 前期的实现方案和周期都已有报价的依据，谁没事帮你们试错？
我觉得客户未必买账，就如很多年前，你如果找的那家外包公司，给方案给你却不接受你的改需求，你会买账吗？

你们都是有多大的项目等着你去上啊....
我自身经历而言：
80%性能问题出在 mysql 身上，php 都是在等 mysql 的结果导致挂死，大量并发下问题更能复现。除了优化 mysql 语句和增加缓存机制，还能在 php 身上找问题？
15%性能问题是出在带宽上，真的自己做过压测就知道了，别说 10k 并发，5k 并发所需的带宽是多少？而现在云服务器都是 5M~10M 居多吧？这个带宽下能支持多大流量？机器转包率能达到多少？
5%性能问题是 phpfpm 机制导致的，比如无法有效实现连接池和常驻还有协程....但连接池 /常驻 一直有个叫 workman 的框架在支持，而协程则有 swoole 提供框架。

所以我觉得大多数场景下，遇到的瓶颈并不是“语言”导致的。

@Michelangelono #24 微信支付的话有 IOT 模块，但是我没了解过这个接口。
如果是使用 H5/微信 支付这些接口的话，建议是公网服务器进行接收支付回调，相比客户端设备的网络而言，公网服务器网络稳定很多。

车进库->识别车牌-> [ 工控机 判断是否白名单，记录数据，推送给服务器 ]
车出库->识别车牌-> [ 工控机 判断是否白名单，轮询服务器支付结果]

月租客户：
公众号进入 H5 页面，输入车牌，线上支付月租费用。
工控机：间隔 30 分钟同步一次服务器月租数据。

单次停车：
公众号进入缴费 h5 页面，输入车牌，线上支付费用。
工控机：间隔 1 分钟同步一次服务器支付数据。

如果长连接的话把间隔 X 分钟去掉，有信息服务器推给终端设备即可。

工控机做好数据的同步，
1 、局域网管理的数据，同步上服务器；
2 、服务器的数据，同步到工控机；
自行考虑当断网或人工操作情况下导致数据冲突的情况即可了。要么服务器的为主，要么本地为主......

预案：
断网：
断网前已开通月租的车辆不受影响，临停车辆支付信息如果在断网前有同步到工控机的也不受影响，其他情况只能人工兜底。

服务器异常：
影响：临时付费的，开通月租的，但已开通月租或已付费临时车不受影响。这一步一样只能人工兜底。另外可以通过监控自主发现异常，一般可能性比较少。

服务器炸了这个情况估计比较少，
哪怕你们有 100 个客户，并发数也高不到哪里去。

如果是轮询形式的，可能服务器压力会大点，
如果是长连接形式的，服务器压力会小很多（因为不需要轮询）

而且停车场出入这些，除非你们是打算做 0 人工值守的，否则有人工做兜底，就算出问题也不会太大。

1 、长连接就是建立持久的 tcp 链接。
优点：不需要频繁创建销毁，创建链接后后续消息载体直接通过连接发送，并且可随时客户推去服务器 /服务器推客户端。
缺点：自行维护链接，如网络波动或异常时做好重连。

2 、3 、非性能场景下，其实看维护简易度。这个看你们公司吧。


我之前是 http 短连接的形式，因为不需要服务端推送数据给客户端，都是客户端请求服务端，但是如果联网异常的话没法告警，只能显示屏上显示断网。你用长连接的话可以自己监控链路状态，持续异常多久则服务端发出告警信息。*短连接其实也可以告警，只是我们当初的场景对这个不敏感。

这个是相对的，而不是绝对的。
比如
SET UNIQUE_CHECKS = 0 ，关闭唯一性校验；
如果作者测试的时候瓶颈大部分是 CPU 进行检验，而你测试的时候 CPU 并非瓶颈，那就会出现 你测试的效率和作者测试的效率不一样。

这就是调优存在的意义，并不是把配置复制黏贴就完事，而是根据实际情况找到瓶颈所在，再进行优化。

@Michelangelono #18
DDNS 主要解决的是动态 IP 的问题，但是如#19 所说，DDNS 最大阻碍就是部分地区运营商不分配外网 IP ，移动家用 100%没公网 IP 且不支持申请。

另外长连接效率确实是更高，并且当工控作为客户端连接服务器时，可以忽略公网 IP 的问题，但是长连接需要自己维护好，主要是心跳重连这一块。

我上面提到的那个项目当时考虑到信息量性能要求不大，所以没使用自行维护长连接，用的是 http 协议的短连接，权鉴直接用 http auth 就可以了。

DDNS 一般第三方都有免费 API ，把外网 IP 获取后通过 API 同步过去就行了。


@coala #19
X86 工控机性价比确实不高，但是解决了占位和功耗的问题，不是 mini 笔记本，是 itx 主板。itx 的由于是 x86 所以基本兼容大部分语言作为客户端。
如果有崁入式开发经验的，其实 arm 系列的才是最优选择，无论从功耗还是稳定性来说，之前看过 jvm on arm ，但不清楚具体如何，如果 jvm 能在 arm 上完美运行，其实买个 arm 系列的工控可能会更加好。


另外 mqtt+流量卡 好像是现在 IOT 的标配，建议可以关注一下。

@Michelangelono #8 另外用什么语言，
我觉得应该看你的终端设备支持什么语言控制吧，比如我之前弄的二维码扫码的，只有 dll 接口，那就用 C#来写。
说白了这个控制机只是作为一个控制终端设备，并暴露接口给服务器调用即可。

@Michelangelono #11
工控机就做管理就好了，对外提供接口即可。
如：
进：摄像头->车牌->工控机(本地判断是否车位已满)->闸机开
出：摄像头->车牌->工控机(计费方式)->已缴费 /包月 /特殊车牌->闸机开

工控机 API->（ web 形式提供公网 /局域网调用）
1 、获取车牌列表
2 、获取车牌详情
3 、修改 /删除 /新增车牌信息（包月 /特殊车牌..）
4 、获取账单
5 、开闸 /关闸
。。。。。

这样就可以不需要强同步，客户端随便上个 electron ，然后通过本地 api 管理工控机的数据。
如果要外网管理，那通过 ddns 的形式，让外网能访问这台工控机的 api 即可。

@markgor #10
说错了，早期是
服务器->本地服务器(nodejs/sqlite)->触摸屏工控机->窗口二维码摄像头
后期改为
服务器->触摸屏工控机->窗口二维码摄像头

一开始是本地服务器是为了缓存第二天点餐信息，后来由于多一台机器多一个维护所以把它取消了。
另外 触摸屏工控机 上是用 C#开发的界面，主要是显示二维码识别信息和外接音箱播报。
那时候还专门问老板取消了本地服务器的话那断网怎么办。
老板说把产品改名云就餐系统就行了........
最后一直稳定运行至今.

@Michelangelono #8
C -> C++ -> (JAVA/JS/PY/GO/PHP....)
你要看你工控机配置在去选择，最求性能稳定性的那就 C/C++，资源利用充足且相对稳定。
我之前弄过就餐类的，场景是提前一天 18:00 前确认次日中午 /晚上是否就餐，次日通过二维码识别进行取餐。
后台是 PHP ，本地机器（ x86 工控）是 nodeJS 。

不过你这种场景我不清楚，我用过的停车系统都是包含微信支付的，如果你这个也涉及线上支付的话，要考虑网络环境，一般都是 支付网关<->服务器<->工控机，很少会直接支付完->工控机，这种我只见过崁入式硬件有直接和第三方支付对接的。

问题不大吧。
现在停车管理基本这样，但是否 java 跑脚本...我就不清楚。
闸机-摄像头
|
工控机 /x86
|
配置分发(局域网 /互联网)


@l1ve #1 一般定期上传都是做备份而已，实际业务估计本地机器进行处理了。

@seasonsolt
1：我现在就是这样做，但换来的不是业务来吵就是财务来吵。
2:淘宝双 11 退款规则和 LZ 提到的退款一样是按比例退且红包部分不退啊。
3:之前搞调拨货损时就是这样做的，但和财务做账方式不同，财务做账时候又用其他方法抹平

@mokevip img 的同时加载才是主要的，另外浏览器依然对加载有并发数量限制。最后小程序只能 https ，并且小程序的前端代码是托管在小程序所在平台的

@seasonsolt #8
按你的逻辑,
1 、"运费均摊到商品上，算出一个商品成交价格"
> 如果运费 2 元，但买了 3 个商品，那小数点怎么计算。

2 、如果是满 10 元-1 元，成交价为 10 元，-1 元后实付 9 元，当发现部分退款的时候这个满减优惠怎么办？

3 、“重量 /体积 的维度”怎么均摊去别的产品？
>比如我买 1KG 哑铃和 1 个 50G 沙包，你均摊后每个物品 525G 计算？那我把 50G 的产品退掉了，1KG 的运费直接按 525G 计算吗？

@monster33 #51 你知道为什么上面都没提及性能排序吗？
因为他们默认配置下性能相差不会特别大，我没实测过，但我觉得这些上了年头的服务，性能相差最多类似±10%左右。
对于云厂，他们缺的可能不是这些性能，而是二次修改便捷程度和稳定性这些吧。
对于个人用户，大多一把梭 装个 lede 、nas 等的跑下小型的应用，对性能基本不怎么关注。
可能会关注的只有便捷性和是否支持 GPU 直通硬解这些吧。

就好像你的网站能承受 10K 并发，和能承受 10.3/10.2/10.5...这样对于现实环境中意义并不大。