V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lesismal  ›  全部回复第 48 页 / 共 63 页
回复总数  1246
1 ... 44  45  46  47  48  49  50  51  52  53 ... 63  
2021-11-17 19:04:40 +08:00
回复了 lesismal 创建的主题 Go 编程语言 最近犯闲,想再写点啥项目,有推荐的吗?
@XTTX #9

不同体量的 IM 项目架构差别很大,比如几种:
1. 上古时期的 web 实时聊天室,网站总在线量不大,随便起个名字进房间,主要是文字或者固定表情,并且单房间在线数一般不打,实现逻辑简单,需要踩坑性能的也就是广播时候可能会涉及广播风暴需要做点批次合并发送的优化
2. 目标在线量不大但是有更多功能的 IM ,比如企业内办公用的,除了文字和固定表情,常见的传文件、发自定义图功能也有,因为在线量不大,数据、文件存储层不涉及太多,也不需要太复杂的分层、路由设计,单体架构随便都能搞定
3. 海量在线,比如 QQ 这种,文字表情文件图片语音等各种功能,除了代码架构的分层设计、路由,还需 CDN 各种运维相关的工程部署,需要数据库、缓存、小文件存储各方面的横向扩容机制,需要多机房等各种

每种定位不一样,人力、资金成本和架构、开发周期也差别大,只能按实际的搞,但单纯从需要的技能点来讲,长连接协议交互这块都不算难,更多难点是工程、尺度上的设计。

开源的有一些也可以作为参考:
B 站毛大的:
github.com/Terry-Mao/goim
前微信大专家:
github.com/OpenIMSDK/Open-IM-Server

我只是看到过社区、公众号之类的推这些开源项目相关的信息收藏起来了,没有深入研究,所以没有了解他们具体的架构、能够支持的用户量级和业务场景,通常够用了,自家可以定制化。

IM 支持的消息,需要分类对待:
1. 文字 /表情,表情也是可以 id 指代的所以也相当于文字,nosql 系的数据库有好些,或者 tidb 或者自己设计可以方便横向扩容的存储层都可以
2. 图片音视频或者其他类型的各种文件,需要文件存储的基础设施,开源的也比较多,开源直接拿来用,这其中可能还涉及小文件存储,应该跟大文件区分开,文件元信息也是可以放到数据库里,头条的小文件存储元信息好像是放到 tidb 里的

如果目标在线量不大,那就简单得多了

如果有兴趣积累 IM 的技术,你可以尝试自己动手从零开始搞一个,我那个 arpc 能够作为 IM 的长连接协议交互基础设施,最简单的就房间文字聊天转发,很简单,这里有个例子:
https://github.com/lesismal/arpc/tree/master/examples/webchat
2021-11-17 15:51:12 +08:00
回复了 lesismal 创建的主题 Go 编程语言 最近犯闲,想再写点啥项目,有推荐的吗?
@XTTX #4
> 一个 ip 支持同时 65k 个 ws

这个说法不准确。一个 ip+一个 listen port ,跟另一个 ip 最多可以 64k 个连接,这还要受到系统参数限制比如 net.ipv4.ip_local_port_range 。

四元组的概念是基于 3 层的 ip 协议,四元组包括:
A IP && A PORT - B IP && B PORT

ip 协议 port 字段是两字节,而 tcp server 通常是 listen 固定的 port ,相当于 A IP && A PORT 固定,对于另一个 IP ,相当于 B IP 也固定,所以只剩下 B PORT 范围可变,所以就受 port 字段类型的限制,2 字节,64k ,再加上内核参数的限制。

但是如果 tcp server 监听 n 个 port ,B IP 就可以跟 A IP 建立更多连接数:n * min(64k, 内核参数限制)。

所以很多人单机测百万连接数要搭建 docker 或者虚拟网络,我为了省事,直接开多个端口,免去搭建的麻烦了:
github.com/lesismal/nbio-examples/blob/master/websocket_1m/server/server.go#L68
2021-11-17 15:37:52 +08:00
回复了 lesismal 创建的主题 Go 编程语言 最近犯闲,想再写点啥项目,有推荐的吗?
@kksco
网络协议涉及的知识稍微多一些,实现一个只处理收发的网络库本身涉及的东西其实不算多,熟悉和理解阻塞非阻塞同步异步这些,熟悉 epoll 基本就可以了,甚至从零开始熟悉,边搜资料边实现个简单的 epoll server ,把 et|lt 都试试,跑跑压测,几天就玩明白了,再不济,随便搜几个开源的 epoll server 代码读一读就好了,网络库的读写部分代码量不需要很多,很容易就搞懂了。

然后是需要一些周边的东西了,比如定时器、io 线程池、逻辑线程池,然后再搭配其他基础设施,传统 c/cpp/java netty 都是异步为主的这里是线程池,go 是协程池,有一定差别,因为有协程的亲和性也好、gc 也好、代码指令速度也好,相比 c/cpp 肯定要差一些,所以通常不像主流的 c/cpp 网络库那样逻辑单线程,所以就会有多逻辑并发流相关的设计。再然后就是 http/websocket 这种 7 层协议的支持。

还有内存相关的优化,c/cpp 可以用 tcmalloc/jemalloc 之类的内存池,go 自带 gc 但是在异步网络库场景可能会造成比标准库同步方案更浪费内存的情况,所以可能也需要结合业务自行设计 pool 来优化内存使用。
另外 go 缺少异步的 tls 库,我 copy 1.6 的标准库 tls 魔改支持了异步,并且把 tcp 层 Conn 读写与 tls 、http 、websocket 都打通了共用内存池,尽量减少了开销(某些极端场景也会消耗较大内存,但通常按照业务实际情况可控)。
过去的几个月里,tls+内存池优化消耗了我最多的时间,因为 tls 本身的复杂+异步流解析+内存的精确分配释放确实有点烧体力。

关注过一些国内大厂人的开源视频流服务器,但简单 review 了下代码,有的地方 map 的并发读写都没处理好,高并发时容易出现 panic 、整个进程挂掉,所以前阵子其实还想搞一下视频编解码多协议的支持来着,但估计了下,实在是消耗体力,还是先算了。

需要注意的一点是,nbio 这种异步网络库,连接数少的时候并不比标准库一个连接一个甚至两三个协程的方案有响应速度的优势,甚至是劣势。标准库占用更多内存,但响应性可能更好。只有在连接数较大、协程数量带来的内存、gc 、调度等开销达到临界点时,nbio 才会有明显优势、服务更稳定。因为异步解析以及消息处理要丢给逻辑协程发生调度、不如标准库同协程内那么亲和性友好。nbio 的能力是可控的协程数量,比如 1000k 连接数我可以控制在 100 、1000 或者 10000 个逻辑协程处理,不会因为连接数暴涨而协程数量爆炸导致明显的 STW 甚至 OOM 。

之前有打算整理一份详细的 nbio 的设计与实现,但是列了一些提纲后发现展开了说够写一本书了,想写好点的话弄本书,参考之前一些首次出书的作者的心路历程,这个工作量业余时间搞至少需要一两年,所以暂时放弃了,以后如果有体力再考虑。并且网络库相关的,市面上已经有不少书了,传统好书看 Stevens 的 tcp/ip 详解卷一,卷二和卷三就不用看了,纸上源码确实难啃而且有些老旧了,UNP 两卷,网络那卷应该算必读吧,进程间通信那卷也可以看看,至少对 uni*发展史和基础的 IPC 机制都能有些了解,而且 Stevens 的书都写的很好,读他的书就像在跟他交流一样,APUE 也是这样子的。
其他的一些书,linux 服务器、高性能相关的,陈硕老师傅有个 cpp 的 muduo 框架和书,我没怎么研究过,但扫了一眼书的目录还挺全面的,可以读读看
2021-11-17 15:02:26 +08:00
回复了 lesismal 创建的主题 Go 编程语言 最近犯闲,想再写点啥项目,有推荐的吗?
@XTTX #1 每个人备份需求不一样,这个得自己搞,查找的话本身挺简单的,小工具按条件遍历下目录就行了
2021-11-11 10:37:33 +08:00
回复了 grimpil 创建的主题 Python 从 10 亿位数字里查找指定的数字,怎样才能快一些?
@c0xt30a 不用那么麻烦的 hash ,要查询的数字 n 具有上下限并且值范围不是特别巨大,用要查询的数字 n 作为数组下标就行了,数组的值就是 n 对应的在 pi 中的 index
@arthurire KMP 是 O(m+n) 的,字符串本身达到 10 亿量级,O(m+n) = 10y+8 也是没法接受的

#34 楼已经实现,建好数组就相当于位图了,时间复杂度 O(1)
2021-11-11 00:22:06 +08:00
回复了 grimpil 创建的主题 Python 从 10 亿位数字里查找指定的数字,怎样才能快一些?
算了,忍不住还是调试了下,完整版的:
https://gist.github.com/lesismal/c4528eacc35db33f754ac2f8eb9e7634
2021-11-10 23:53:39 +08:00
回复了 grimpil 创建的主题 Python 从 10 亿位数字里查找指定的数字,怎样才能快一些?
#32 文件尾、打开写文件的好像都有问题,平时不写 py ,实在不熟悉,v 站发代码也确实难受,对齐好像都没了
2021-11-10 23:46:44 +08:00
回复了 grimpil 创建的主题 Python 从 10 亿位数字里查找指定的数字,怎样才能快一些?
用数据库存上也是慢,内存里缓存起来性能最好了,下面代码大概意思是 converter 先统计好索引到数组,然后把数组写入到文件,finder 读入文件初始化数组,然后再查找。没仔细调试,因为太烧机器了,有兴趣的同学可以完善下:

1. converter.py
```python
# -*- coding:utf-8 -*-
#!/usr/bin/python3

import datetime

class PIConverter:
def __init__(self, minNum=100000, maxNum=99999999):
self.minNum = minNum
self.maxNum = maxNum
self.positions = [0]*(self.maxNum+1-self.minNum)

def convert(self, srcFile, dstFile):
fsrc = open(srcFile,'r')
fsrc.read(2)
try:
lastStr = ""
readSize = 1024*8
currPos = 0
readed = 0

starttime = datetime.datetime.now()

offset = len(str(self.minNum)) - 1
while True:
s = fsrc.read(readSize)
s = lastStr + s # 这里可以再优化下
currPos -= len(lastStr)
for i in range(len(s)-8):
strLen = len(str(self.minNum))
while strLen <= len(str(self.maxNum)):
subs = s[i:i+strLen]
strLen += 1
num = int(subs)
index = num - self.minNum
if self.positions[index] == 0:
self.positions[index] = currPos + i

if len(s) == 0:
break

lastStr = s[len(s)-5:]
currPos += readSize
readed += readSize
if readed % (1024*1024*8) == 0:
print("total read: {}, time used: {}s".format(readed, (datetime.datetime.now() - starttime).seconds))

print("total read: {}, time used: {}s".format(readed, (datetime.datetime.now() - starttime).seconds))
print("done")

try:
fdst = open(dstFile,'rw+')
for index in range(self.positions):
fdst.write(str(index)+"\n")
finally:
fdst.close()
finally:
fsrc.close()

def find(self, n):
if n < self.minNum or n > 99999999:
return -1
return self.positions[n - self.minNum]

piConverter = PIConverter()

# 把已经统计出来的生成更小的文件
piConverter.convert("./pi-billion.txt", "./pi-position.txt")

# converter 初始化太慢了,所以最好还是先 piConverter.convert 把已经统计出来的生成更小的文件,finder.py 用该文件初始化和做查找
# print("141592:", piConverter.find(141592))
# print("415926:", piConverter.find(415926))
```

2. finder.py
```python
# -*- coding:utf-8 -*-
#!/usr/bin/python3

class PIFinder:
def __init__(self, fname, minNum=100000, maxNum=99999999):
self.minNum = minNum
self.maxNum = maxNum
self.positions = [0]*(self.maxNum+1-self.minNum)
f = open(fname,'r')
try:
i = 0
for line in f:
num = int(line)
self.positions[i] = num
finally:
f.close()

def find(self, n):
if n < self.minNum or n > 99999999:
return -1
return self.positions[n - self.minNum]

piFinder = PIFinder("./pi-position.txt")
print("141592:", piFinder.find(141592))
print("415926:", piFinder.find(415926))
```
是什么工作内容非要远程到其他员工电脑上?

日常见过的,即使安全相关的部门,也只是监控流量之类的、不至于非要日常频繁远程到其他员工电脑上操作吧

如果工作内容就是必须这样,是不是这个工作内容本身就恶心、应该一块喷喷老板而不是 /t/813228 楼主?就像是顾客投诉滴滴司机和美团送餐员,大家都不容易,反倒被资本家转移了矛盾互相斗

而且,如果确实必须要远程到其他同事电脑上,又不是瞎子,而且看之前也不知道啥是该看不该看、谁能保证啥也不看呢,不要用神的标准要求人。
2021-11-05 17:48:49 +08:00
回复了 MID 创建的主题 MacBook Pro M1 Max 对比 M1 Pro 电池续航对比的详细评测出来了
感情现实里净是一群不插电玩家啊
你们还给不给 wintel 家早泄选手活路了 :joy:
2021-11-02 12:22:59 +08:00
回复了 jiobanma 创建的主题 Apple Mac 下有什么还用的 ssh 工具吗
每次看到楼主头像这一屁股都觉得别扭
2021-10-31 01:32:37 +08:00
回复了 justaname 创建的主题 MacBook Pro 似乎 16 寸 Max 比 Pro 的续航要少很多呀
和妹子约会前以为可以嗨翻整夜,实际流程走下来也就那么春宵一刻——人们总是以为自己在某些事情上需要很长时间或很怎么样的配备,比如觉得生产力的 mbp 应该很轻薄、续航应该很久、刘海屏应该去掉释放更好的 UI 空间。

只有像我这样聪明的人,早就告别了单纯,对于 mbp 的抵触,完全是因为穷。
2021-10-11 11:06:35 +08:00
回复了 sickoo 创建的主题 哔哩哔哩 有必要再续费大会员吗?
B 站变了,但被资本裹挟后,哪个公司能真的保持清高呢?要想让它再变好,反倒是需要我们在它变的时候继续支持,直到有一天资本满意了再次放宽了情怀,才会再把那个 B 站还给大伙
2021-10-09 13:37:11 +08:00
回复了 nanmu42 创建的主题 Go 编程语言 Go 语言错误处理的姿势
@XTTX 不客气。国庆结束了,好好写代码持续输出。
2021-10-06 20:42:06 +08:00
回复了 nanmu42 创建的主题 Go 编程语言 Go 语言错误处理的姿势
#46 更正结尾处:确实心境还不够,少打了个“不”
2021-10-06 20:38:33 +08:00
回复了 nanmu42 创建的主题 Go 编程语言 Go 语言错误处理的姿势
@XTTX 我已经解释过两次了,不是翻你黑史,而是那个帖子先有了印象所以加上这个帖,但凡你前面仔细看下我在说哪个点,我至于掰扯这么多、提那个帖子?因为你不把观点表达清楚、回复之前那个哥们也没 at 别人,回复我也不看我是在说哪个点,所以才会联想到你之前帖子、聊技术太随意了。

另外,也别上纲上线的弄好像我人身攻击你一样,这两个帖子你要是不那么随意,也不会有这么多互喷。我抱怨下就成了我故意攻击你?那你随意在先、并且我都回复了那么多似乎直到上一条你才看懂我在杠什么,那你就尊重别人了?麻烦你能不能讨论的时候认真点先?

再说,技术的事情,就事论事,该严谨的地方,怎么就不能杠精了?十几年前,或者至少八九年前,技术群还没那么多,好多人都是论坛上交流,一个技术问题,一群人争论得没完没了,随便盖出几十几百楼,就比如源码的事情,尤其是底层的一些、源码级别相关的,大家都非常重视,一丁点细微差别都可能是天差地别,经常都能杠得各自在各自电脑前面红耳赤,但是技术的问题,杠完了大家都更清楚了,也不会因为杠技术本身而觉得彼此伤害了。反倒是遇到随便拿来什么就信口开河满嘴跑火车聊技术的会让大家郁闷。技术的事情,从论坛到工作到开源,包括内核社区,即便不是三天两头,也是隔三差五就会有杠的事情发生,认真杠一些事情才争论的清楚,不信你去翻翻 linus 大神历史。

说我杠精行为就杠精行为吧,我承认,对于技术,我确实比较杠。
但是,杠精就不对了?专业领域的杠,别人还夸你认真钻研呢,如果都不杠了,高级的科学家、工程师、设计师各种估计都得绝种。都不杠了,小白错误言论满天飞,更多小白被带歪。技术不是娱乐圈,虽然拿娱乐心态聊技术不违法并且是你的自由,但既然你不认真了,也麻烦你不要怪罪别人认真对待技术的人。

如果你觉得就这么一句"standard lib"无关大雅无关紧要,那好,你继续随意吧。你可以自己回顾看下,这两个帖子你对技术的点是不是不够认真,这个帖子提到源码相关的,我猜测你没有怎么研究过。如果没研究过,就没必要随口就说关于它的事情、对更多小白会造成误导。

并且再强调一次,我是先看到的那个帖子然后才注意到这个帖子,不要以为别人有心情故意去黑你,你没那么重要,我也没那么重要。聊技术,就按技术论技术完事了,
我提那个帖子只是说你不认真,但是反过来给我扣的帽子是我搞人身攻击,想问下,到底谁在人身攻击谁?

这两天这个帖子说太多了,浪费了自己时间,也浪费了大家的时间。抱歉了各位,以后我尽量忍住、少回帖。
如果这种行为不好,站长封我我也认,确实心境还够,需要继续修炼学会忍耐与安静。
2021-10-06 11:18:27 +08:00
回复了 nanmu42 创建的主题 Go 编程语言 Go 语言错误处理的姿势
回到技术问题上,我也赞成 named/naked 不好,go 源码里虽然也有这样用,但仍然也不建议大家这样用。

go 源码有很适合用来学习,建议有兴趣的同学多读读。
2021-10-06 10:31:39 +08:00
回复了 nanmu42 创建的主题 Go 编程语言 Go 语言错误处理的姿势
1. “<<为什么不要用 naked return>>” —— 我没反驳过,我觉得这么说是 ok 的。
2. “standard libs 都用一种方式” —— 我反驳的是这个,因为源码里有这种方式,我引用的代码就是 go 源码

如果分不清我是在说 1 还是在说 2,那就停了吧。如果没读过 go 源码,甚至不知道 go 上面引用的就是 go 源码,那你随意吧。
2021-10-06 10:23:18 +08:00
回复了 nanmu42 创建的主题 Go 编程语言 Go 语言错误处理的姿势
“这两段来自同一个你引述的 package, 什么叫双重混用。这种代码读起来就不是非常舒服。你可以举证为什么这种代码是最优雅的”
—— 所以你是真看不懂是吧。我上面说了,没有反驳这个是不是优雅。我针对的是,你说 std 里只有一种方式、std 里没有这种方式,而我引用的代码就是 std 里的、有这种方式。我上面都解释过了我也不觉得这样好,但不好跟没有是两码事,不要自己可能都没读过源码就随便说源码里没有。

“一言不合你就开始翻我的 post 记录,找找能人身攻击的东西,就差人肉了吧”
—— 上面也解释过了,是先看到你那个帖子里,又看到你这个帖子里,你对技术的观点太随意了。你可以再看下我 #29 楼中的第 2 条。

如果说前面是我自己以为你在回复我、算是我瞎,那后面回复了这些跳,解释了好几次,你没一次看懂了。另外,别提了另外个帖子就上纲上线的人身攻击转移话题,同为讨论技术的态度不严谨,要掰扯那正经点先把源码里有没有这种方式的事情扯清楚。我都强调过了那个就是源码、里面有这种方式、你都不正面回复又。反而我都强调过了我没说 named/naked 好,你也看到过了然后又来继续解释这个不好,我纠结它好不好了吗?
2021-10-06 00:14:49 +08:00
回复了 nanmu42 创建的主题 Go 编程语言 Go 语言错误处理的姿势
@XTTX #31 又是说 “所有的 std libs 都有明确的 return”。我引用那几行代码就是 go 源码,你看看有没有 named 和 naked 。如果说我之前错以为你没 at 人那一层是在回复我,那是我理解错了。但是我感觉我之前说的啥你也没看懂
1 ... 44  45  46  47  48  49  50  51  52  53 ... 63  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1111 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 49ms · UTC 23:09 · PVG 07:09 · LAX 15:09 · JFK 18:09
Developed with CodeLauncher
♥ Do have faith in what you're doing.