朋友们好，有个C++写TCP服务器，之前客户端都是PC或者手机客户端通过TCP连接进行各种握手交互，现在客户端是WEB，请问有什么好的方法？

lijian910wolf 2020-09-12 08:22:13

朋友们好，有个C++写TCP服务器，之前客户端都是PC或者手机客户端通过TCP连接进行各种握手交互，
比方客户端TCP连接服务器，交互数据，指令等等，都是彼此实时。
现在客户端是WEB，请问有什么好的方法可以彼此实时交互数据，客户端可以下达数据到服务器，服务器可以主推数据到WEB客户端？
谢谢

...全文

381 9 打赏收藏转发到动态举报

写回复

用AI写文章

9 条回复

切换为时间正序

请发表友善的回复…

发表回复

lijian910wolf 2020-09-25

打赏
举报

引用 8 楼陈仲甫的回复:

[quote=引用 7 楼 lijian910wolf 的回复:][quote=引用 6 楼陈仲甫的回复:]根据你的描述，需要频繁访问的设备记录大概只是一个终端ID和少量附加信息，那么这些可以存放在后台的DB中，可能不需要上redis，尤其不需要直接redis做存储并拆分出这一块数据出去，因为你后台的DB很可能也要引用这些数据，单单为了一点数据的访问速度去做整体架构的拆分，不值得。不如把需要频繁访问的记录用redis做个缓存就好了，甚或是自己做个map\unordered_map的缓存也行啊（千万级别数据是没问题的，如果这点数据真的那么频繁使用，加一条16G的内存 300块，便宜得很，实际工程中这点成本可忽略不计） web前端服务器用到的数据仍然建议放到后台db中，如果是它只需要一部分比较冷的数据，可以做个间隔时间较长的缓存策略，定期同后台DB交换数据。数据全部在后台DB，逻辑上好理解，备份恢复调试起来都方便，要分片也可以在后台做，通常这就够提供足够的性能了。毕竟你的后台和前端大部分情况下是高速直连的，为了省这个通信开销去动架构，好像太贵了。

设备权限记录这个访问要速度，因为高并发的时候如果每个设备上线都去数据库里查询它是否有权限上线是不是会变的很慢？至于设备产生的数据，跟WEB端进行的些其他附件设置，这个访问的话，要体验好的话肯定是要查询速度快些，要不应该也能接受查询数据慢些的状态[/quote]可做缓存而而不需要拆分　你可以先确认一下总共会有多少设备并发上线又会多少算一个初步的指标脱离需求的架构就没有适用不适用了 [/quote] 嗯，这个说的正合我这几天规划的方法。这几天直接用开辟内存的方法处理，比用redis会更好把控。现在就是怎么把第一次加载到内存里弄的快些。之前我是把设备权限信息后台同步到硬盘文件上，然后每次启动服务器时用内存映射的方式启动。直接从数据库里读取有点慢，但是多加一个中间文件（记事本文件）感觉又复杂了一步结构

an_bachelor 2020-09-25

打赏
举报

引用 7 楼 lijian910wolf 的回复:

[quote=引用 6 楼陈仲甫的回复:]根据你的描述，需要频繁访问的设备记录大概只是一个终端ID和少量附加信息，那么这些可以存放在后台的DB中，
可能不需要上redis，尤其不需要直接redis做存储并拆分出这一块数据出去，因为你后台的DB很可能也要引用这些数据，
单单为了一点数据的访问速度去做整体架构的拆分，不值得。
不如把需要频繁访问的记录用redis做个缓存就好了，甚或是自己做个map\unordered_map的缓存也行啊（千万级别数据是没问题的，如果这点数据真的那么频繁使用，加一条16G的内存 300块，便宜得很，实际工程中这点成本可忽略不计）

web前端服务器用到的数据仍然建议放到后台db中，如果是它只需要一部分比较冷的数据，可以做个间隔时间较长的缓存策略，定期同后台DB交换数据。
数据全部在后台DB，逻辑上好理解，备份恢复调试起来都方便，要分片也可以在后台做，通常这就够提供足够的性能了。毕竟你的后台和前端大部分情况下是高速直连的，为了省这个通信开销去动架构，好像太贵了。

lijian910wolf 2020-09-25

打赏
举报

引用 6 楼陈仲甫的回复:

根据你的描述，需要频繁访问的设备记录大概只是一个终端ID和少量附加信息，那么这些可以存放在后台的DB中，可能不需要上redis，尤其不需要直接redis做存储并拆分出这一块数据出去，因为你后台的DB很可能也要引用这些数据，单单为了一点数据的访问速度去做整体架构的拆分，不值得。不如把需要频繁访问的记录用redis做个缓存就好了，甚或是自己做个map\unordered_map的缓存也行啊（千万级别数据是没问题的，如果这点数据真的那么频繁使用，加一条16G的内存 300块，便宜得很，实际工程中这点成本可忽略不计） web前端服务器用到的数据仍然建议放到后台db中，如果是它只需要一部分比较冷的数据，可以做个间隔时间较长的缓存策略，定期同后台DB交换数据。数据全部在后台DB，逻辑上好理解，备份恢复调试起来都方便，要分片也可以在后台做，通常这就够提供足够的性能了。毕竟你的后台和前端大部分情况下是高速直连的，为了省这个通信开销去动架构，好像太贵了。

设备权限记录这个访问要速度，因为高并发的时候如果每个设备上线都去数据库里查询它是否有权限上线是不是会变的很慢？至于设备产生的数据，跟WEB端进行的些其他附件设置，这个访问的话，要体验好的话肯定是要查询速度快些，要不应该也能接受查询数据慢些的状态

an_bachelor 2020-09-23

打赏
举报

根据你的描述，需要频繁访问的设备记录大概只是一个终端ID和少量附加信息，那么这些可以存放在后台的DB中，
可能不需要上redis，尤其不需要直接redis做存储并拆分出这一块数据出去，因为你后台的DB很可能也要引用这些数据，
单单为了一点数据的访问速度去做整体架构的拆分，不值得。
不如把需要频繁访问的记录用redis做个缓存就好了，甚或是自己做个map\unordered_map的缓存也行啊（千万级别数据是没问题的，如果这点数据真的那么频繁使用，加一条16G的内存 300块，便宜得很，实际工程中这点成本可忽略不计）

web前端服务器用到的数据仍然建议放到后台db中，如果是它只需要一部分比较冷的数据，可以做个间隔时间较长的缓存策略，定期同后台DB交换数据。
数据全部在后台DB，逻辑上好理解，备份恢复调试起来都方便，要分片也可以在后台做，通常这就够提供足够的性能了。毕竟你的后台和前端大部分情况下是高速直连的，为了省这个通信开销去动架构，好像太贵了。

an_bachelor 2020-09-19

打赏
举报

引用 3 楼 lijian910wolf 的回复:

[quote=引用 2 楼陈仲甫的回复:]可以在服务端加一层适配服务，将TCP指令交互转为http的通信，也就是给你的TCP后台加个专用的web前端，如果交互性要求比较灵活这个前端可考虑用websocket。

感谢。
有考虑过加一个websocket，实时交互强。但增加工作量复杂度。
我现在在想，前端用定时刷新好了，不要服务器主推，

引用 2 楼陈仲甫的回复:

可以在服务端加一层适配服务，将TCP指令交互转为http的通信，也就是给你的TCP后台加个专用的web前端，如果交互性要求比较灵活这个前端可考虑用websocket。

除了加websocket还有什么方法？加这个工作量比较大[/quote]那就直接客户端轮询的模式呗根据业务翻译就行遇到原有服务端推送的情况可以要么不实现（web端减少部分功能通常被认为是“可以接受”的，因为大家会默认web端没那么强大）要么改为间隔一段时间轮询

lijian910wolf 2020-09-19

打赏
举报

引用 4 楼陈仲甫的回复:

[quote=引用 3 楼 lijian910wolf 的回复:][quote=引用 2 楼陈仲甫的回复:]可以在服务端加一层适配服务，将TCP指令交互转为http的通信，也就是给你的TCP后台加个专用的web前端，如果交互性要求比较灵活这个前端可考虑用websocket。

感谢。有考虑过加一个websocket，实时交互强。但增加工作量复杂度。我现在在想，前端用定时刷新好了，不要服务器主推，除了加websocket还有什么方法？加这个工作量比较大[/quote]那就直接客户端轮询的模式呗根据业务翻译就行遇到原有服务端推送的情况可以要么不实现（web端减少部分功能通常被认为是“可以接受”的，因为大家会默认web端没那么强大）要么改为间隔一段时间轮询[/quote] 了解。有个这种问题有点迷糊；我想设计成这样，客户端接入服务器是要权限的，这个权限是WEB端增加的，比方某个设备想接入服务器，先从WEB端新增一个设备都数据库里，设备接入服务器时，服务器端先查询是否有这个设备记录，有就可以接入。但是有这么个问题，这个设备记录是频繁用的，所以想用redis存储，但是服务器可能会分多台主机部署的，把一些设备的数据存储到一个关系型数据库里，然后WEB端的计划就是连一个主机（这个主机会装另外一个关系型数据库用来存储其他非实时要交互的数据，比方前边的设备上报的数据，还有WEB端存储的些数据）。这个结构要怎么设计比较好些，这种要实时交互的数据，还有不怎么需要使用的数据？

lijian910wolf 2020-09-18