@烟雨,只能根据域名或者IP地址进行分流,比如百度网盘走线路A,腾讯视频走线路B。
上传下载自动分离是做不到的,因为任何连接在最开始的时候都是上传(是你连接服务器,此时你是上传方),随后服务器开始发送大量数据,才变成下载,但此时连接已经建立,没办法切换到另一条线路了。
所以必须手动创建规则,在连接还没有建立的时候就决定要走哪条线路。
LevelDB
@c,本来就不应该做这种改变。如果可能会改变又没加锁,就是bug。
@㝶芾厶眵攴䭡,我其实不知道是新特性,只是做理论分析。
@㝶芾厶眵攴䭡,如果编译时已经优化成寄存器拷贝了,就不会有内存分配了。
如果对象很小,可以直接放在寄存器上(<=64位),用值接收者可以更快,因为可以优化为寄存器拷贝,避免了内存寻址。如果用指针接收者,就必须为对象分配内存地址,会稍慢。
@1mm0rtal,用这种方式发送一个启动sw3.exe的
wine.log文件:
https://hu60.cn/q.php/bbs.topic.96470.html#nav
package main import ( "fmt" ) type InterfaceConnection interface { DoSomething() int } type MyConnection struct { id int } func (c *MyConnection) DoSomething() int { fmt.Println("Doing something:", c.id) return c.id } func main() { Connections := make(map[uint64]InterfaceConnection) _workerConnections := make(map[uint64]InterfaceConnection) conn := &MyConnection{id: 1} Connections[1] = conn _workerConnections[1] = conn obj, ok := Connections[1] fmt.Printf("%v, %v\n", obj, ok) delete(Connections, 1) obj, ok = Connections[1] fmt.Printf("%v, %v\n", obj, ok) obj, ok = _workerConnections[1] fmt.Printf("%v, %v\n", obj, ok) }&{1}, true <nil>, false &{1}, true确实不会影响另一个
map的value是同一个&Struct{}
map的delete只是删除了键和值的对应关系,并不会对值做内存释放操作。
除非没有地方继续引用该值,它才会被垃圾回收。
所以直到fmt.Printf("%p", _workerConnections[1])执行完成,&MyConnection{id: 1}才可以被垃圾回收,在此之前它都是有效的。
@1mm0rtal,你选的游戏安装程序是什么格式,是exe吗?
@bigfuji,麒麟990只能使用华为定制的内核,安装第三方内核没有用,就算真的换了应该也启动不了。
@无名啊,可以负载均衡啊,一个直播间对应一个弹幕服务器就行了。
减少弹幕数量和屏蔽的功能都可以在前端实现,字幕轨只是用于提取弹幕内容。
顺便一提直播弹幕,我觉得最有趣的方法是直接把弹幕嵌在视频流的字幕轨里,这样只要前端加个字幕轨提取代码就行了。视频编码器那边,加字幕的工作交给切片服务器就行了,切片是很简单的工作,顺便混合一下字幕不会有什么额外开销。唯一的问题是审核,想删掉嵌入视频的弹幕比较困难
@无名啊,直播间弹幕甚至可以像直播本身一样通过无状态HTTP服务器分发,按时间切片放在不同的json文件里,然后由一个列表(类似m3u8)不断列出最新的json文件名,由播放器自行下载展示。这样就能用分发直播视频流的渠道分发弹幕了。
@无名啊,直播弹幕和群聊的不同点:
- 历史记录:如果对方发消息时你不在线,群聊允许你稍后接收消息,但直播就直接错过了。
- 连接数量:为每个直播间建立一个TCP连接是可接受的,但为每个群建立一个TCP连接似乎不可接受(你可能加入了几百个群)。所以群聊必须由服务器合并你收到的消息,但直播间不需要合并。
- 消息可达性:未收到某个群消息是不可接受的,但未收到某些弹幕完全可以。很多人气很高的直播间弹幕一屏根本放不下,都是裁剪后显示的,每个人都只收到了部分弹幕。
@无名啊,因为每个直播都是一个单独的连接,不需要考虑多个群共享连接,所以采用CDN模型就行了,由一个中心服务器负责发送消息,然后逐级分发给全国CDN,每个人收到的消息都一样。发弹幕则是统一发给那个中心服务器。
