V2EX › OldCarMan 的所有回复 › 第 6 页 / 共 12 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8 9 10 ... 12

❮

❯

2023 年 2 月 19 日

回复了 hsymlg 创建的主题 › 程序员 › 问个概念问题，服务之间 feign 调用算不算 rpc

rpc 只是个概念，feign,grpc,thrift 等你可以理解都是 RPC 的一个个实例，只是他们所支持的序列化方式 /通信协议，特性或功能，想达成的目的等可能不一样而已。

2023 年 2 月 19 日

回复了 OldCarMan 创建的主题 › Java › 关于 non-blocking 数据库 Connector 大家是怎么看待的？

@dreamlike 你意思是语言层面要支持异步 io ，对吧？

2023 年 2 月 18 日

回复了 OldCarMan 创建的主题 › Java › 关于 non-blocking 数据库 Connector 大家是怎么看待的？

@wuhaoecho 嗯嗯，不过个人感觉未来 non-blocking 数据库客户端将会是趋势，现在麻烦主要是，语言生态没有整体发力，就如 java ，最近版本才支持 virtual Thread,市面上又缺乏一整套从控制层到数据访问层的成熟框架，所以推广起来稍微麻烦，不过随着 reactive coding 的发展，未来大概率各个环节都趋向于 reactive 的风格。
@dreamlike 谢谢补充，话说你这里提的 runtime 是指 java 运行时吗？意思是通过重返 runtime 环境，使用 mounting /unmounted （虚拟线程）来控制程序 blocking 的方式吗？

2023 年 2 月 18 日

回复了 OldCarMan 创建的主题 › Java › 关于 non-blocking 数据库 Connector 大家是怎么看待的？

@litchinn 如果你想了解 r2dbc 可以看看我上面#16 楼发的那个链接，r2dbc 是 fully-reactive non-blocking 的
r2dbc 跟 jdbc 一样，只是一个数据库的客户端。
如果想了解 classic jdbc ，r2dbc 跟 virtual thread 的区别，你可以看看这位大佬说的,我觉得讲的很好。https://www.slideshare.net/juarezjunior/revolutionize-java-db-app-dev-with-reactive-streams-and-virtual-threadspdf
两者确实是不同维度的东西，个人觉得现有很多企业的生成环境业务都是使用传统的数据库（ mysql,postgresql 等），而 non-blocking connector 是为了解决这些传统方案的，另外不是每个企业都是随便就能用上分布式数据库的

2023 年 2 月 18 日

回复了 OldCarMan 创建的主题 › Java › 关于 non-blocking 数据库 Connector 大家是怎么看待的？

@xxfye 嗯，确实，不过除了解决连接池占用线程资源外，我认为顺带还有一个提高吞吐量的衍生功能；
你说的 non-blocking 数据库这点即使有必要，但实施起来更加艰难，因为数据库厂商太多了，各家有各家的利益，当然开源的可能阻力稍微少点；
虚拟线程确实是个好东西，不过如果应用层语言是 java,生产环境中应用短时间可行性可能比较低，毕竟 jdk19 才支持虚拟线程，当然如果是其他语言，比如 go 的协程，可能好点，历史包袱没那么大。

2023 年 2 月 18 日

回复了 OldCarMan 创建的主题 › Java › 关于 non-blocking 数据库 Connector 大家是怎么看待的？

@zeni123 哈哈，java 版“协程”是吧，确实 non-blocking 了，但这也意味着相关的框架和库也得跟进
@dreamlike 是的，RT 确实不是重点，正如我了解的一样，真正的异步非阻塞最好得是整套代码（比如 java web 项目从控制层到数据访问层）都使用 reactive 编程
@ychost 是的，你说的 r2dbc 确实我发这个帖子的原因，https://r2dbc.io/ 这好像是他们搞的一系列 reactive 库，感谢你告知我了 oracle 那段。
@yazinnnn 哈哈，有请课代表“协程”出场？
@liuxu 谢谢分享
PS:谢谢大家抽空回复

2023 年 2 月 18 日

回复了 OldCarMan 创建的主题 › Java › 关于 non-blocking 数据库 Connector 大家是怎么看待的？

@hhjswf @billlee 谢谢回复，你们可能把主要问题集中在 I/O 延迟这方面了，当然 I/O 是延迟的主要原因，但根据科特尔定律高并发下一个程序的理想并发量（比如 VU ），除了跟响应时间（包括 I/O 延迟）有关，还跟吞吐量有关，两者都是影响理想并发量的指标，可能我表达不好，个人觉得 nio connector 的主要目的是为了解决后者的问题。

2023 年 2 月 17 日

回复了 MID 创建的主题 › 问与答 › 为什么 New Bing 将近排了两周，都还没有排到？

@MID 哦哦，我两步都没操作，所以怀疑是因为这个。但又搞不懂明明只是体验一下搜索引擎，为啥要搞这两个操作😂

2023 年 2 月 17 日

回复了 MID 创建的主题 › 问与答 › 为什么 New Bing 将近排了两周，都还没有排到？

我也一样，很早就在 waitlist 里了，就是不能使用，话说你们那个“Access the new Bing even faster” （ https://www.bing.com/new/fastaccess ）下的两个条件你们都完成了吗？没法体验是不是因为这两个操作没完成？

2023 年 2 月 17 日

回复了 OldCarMan 创建的主题 › Java › 关于 non-blocking 数据库 Connector 大家是怎么看待的？

@vgbw 嗯嗯，不过个人觉得 Reactor 在有些接入层的应用是一个趋势，比如 spring webflux ，spring gateway 之类的。

2023 年 2 月 17 日

回复了 OldCarMan 创建的主题 › Java › 关于 non-blocking 数据库 Connector 大家是怎么看待的？

@oxromantic 对，确实没关系，这里说的是数据库客户端 connector （就像 JDBC ）；虽然是内网，但是数据库大部分操作是 IO 密集型的，即使少了网络方面的开销，但个人觉得一次数据库操作的主要瓶颈还是在于磁盘 IO 吧；确实很多 connector 不支持 nio 模型，但不支持是因为没必要吗？ mariadb 确实有版本支持了。

@akira 可能不同的应用，不同的需求面临的高并发问题都不一样吧，不过个人觉得数据库瓶颈是很多高并发场景的瓶颈，而假如存在一个自带 NIO 的客户端去处理来自调用者的请求，还是能有效增加数据库操作吞吐量的。

PS:谢谢大家回复。

2023 年 2 月 17 日

回复了 OldCarMan 创建的主题 › Java › 关于 non-blocking 数据库 Connector 大家是怎么看待的？

@liprais 哈哈，观点确实是来自别人的，只不过我觉得他说的有道理而已，但跟很多事情一样，自己觉得对的，不一定是正确的，所以才发贴问大家看法‘。另外个人觉得 non-blocking connector 想解决的是一个应用层的数据库连接吞吐量和伸缩性的问题，而不是一个数据库的消费速度问题，数据库的消费能力决定因素应该是其本身而不在于客户端连接工具上；跟比如 spring webflux 一样，相比 spring mvc 提高了请求吞吐量。
@liprais

2023 年 2 月 15 日

回复了 qviqvi 创建的主题 › Java › 微服务项目如何管理模块，如何用 git 管理版本

有没有一种可能，存在一种比较中庸的方式：

1.相关性比较强的模块可以聚合到一个父模块下（比如你搞一个电商项目，订单中心，仓储中心，用户中心等横向服务，每个中心下的各个子模块整合到一个父模块下，也就是你上面说的方案一）

2.其他公用性 /独立性比较强的，抽出来做单独的模块（比如授权认证服务，日志服务，网关服务，监控服务，统计服务等纵向服务抽离出单独的模块，也就是你说的方案二）

3.如果你说的公共模块只是指代码层面的依赖，那么抽一个公用模块出来写公用代码没问题，不过它只是一个公用代码模块，而不是一个公用服务，凡是服务都是需要部署的，模块不一定要部署；如果它是其他业务服务依赖的公用服务，个人觉得能解耦的尽量解耦到具体业务中，不能解耦的说明其有独立性的必要，单独做一层服务，也就是我上面第一点说的横向服务，问题应该也不是很大。

2023 年 2 月 15 日

回复了 Zach369 创建的主题 › Java › springboot entity 插入字段问题.

@wangxin3 不给默认值，有时会出现一些使用上的问题，比如：某些函数像 sum,count 之类的有时失效，group by 聚合数据时有时也有问题，另外某些场景索引会失效。所以一般情况下都会给个默认值。当然以上纯属个人看法。

2023 年 2 月 11 日

回复了 as9567585 创建的主题 › 程序员 › 什么样的技术可以实现移动端的点对点实时语音， WebRTC 可以吗？

看看这个满足不满足你的需求： https://sipjs.com/guides/mobile/，不过内网穿透服务器是免不了的，而且这玩意如 3 楼所说，好不好取决于用户网络。
我记得腾讯云有这方面专门的服务（ https://cloud.tencent.com/document/product/647/32396 ），叫 TRTC ，不过是收费的，看你的需求。

2023 年 2 月 7 日

回复了 Nazz 创建的主题 › 程序员 › 求教，个人开源项目如何才能快速积累 star

@Nazz 哈哈，然而我只是一个小小的技术仔。我只是从过去别人的一些案例中总结到一点套路，不过说实话，营销确实有助于提高影响力，你看看这两天这论坛又有一个讨论度很高的“很焦虑，高中生”之类的帖子，先不讨论帖子本身，结合前段时间的 14 岁开源库的帖子可以看出，这类的话题就是很容易引起 v 友们的讨论，这也是我上面说的标签化文章和制造话题的作用。不过说个题外话，这也侧面说明这个社区逐渐成为有一部分人引流的地方，这不是我想看到的，但我觉大部分社区似乎都难以逃脱这个命运（就像以前的知乎），毕竟林子大了什么鸟都有。

再补充点建议：技术社区发帖如果有必要可以适当的采取我上面说的这类行为，但自己的博客和开源库就算了，除非你的“博客”不是一个单用户系统而是一个技术社区。

2023 年 2 月 7 日

回复了 Nazz 创建的主题 › 程序员 › 求教，个人开源项目如何才能快速积累 star

哈哈，学会营销，前段时间论坛里有一位 14 岁做开源库求 stars 的 v2exer 就是一经典案例。写技术文章时，标签化文章，提高阅读量；制造话题，提高讨论度；再搞个微信群 /qq 群，来个私域讨论，保留用户粘性，方便用户反馈...

哈哈，开玩笑，当然前面说的算是一种方式吧，不过个人觉得作为一个程序员，应该回归技术本身。
个人平时点 star 的最常用场景是：
1.有用并且代码写的不错
2.出名并且未来可能有用
3.文档写的不错
建议：
写好 readme,复杂项目，最好图文并茂，再复杂的写个 gitbook ，同时写开源项目文章时，想好使用场景，尽量从使用者角度去思考用户什么场景下会用到你的开源项目，便于用户从搜索引擎中找到你。

2023 年 1 月 21 日

回复了 OldCarMan 创建的主题 › 问与答 › 弄一个在线自定义生成节日祝福视频的网站/小程序，有搞头不？

@nickstarthere @miv 哈哈哈，兄弟们挺真实的哈。
@koto 谢谢回复，个人觉得做到和做成是两回事，是不是伪需求是关键。

2022 年 12 月 30 日

回复了 dyxiaodong2022 创建的主题 › 程序员 › 一个 14 岁初中生开发的前端工具库，轻量级高可用，各位可以体验一下

@missx 谢谢邀请,不玩。

@november 结合你说的这些和我 #137 楼说的，再补充一下：

#125 楼利用他 qq 搜到的别人说这 qq 号卖挂的时间点是：2021-11 月份，也就是一年多前这个 qq 号还在卖挂(steam 信息： https://steamcommunity.com/profiles/76561199038158588)，如果是一个卖挂的讲的故事真让人存疑，当然现在这 qq 号可能已经不是楼主的了，但是 2021-08 月份该 qq 号还在发布简单的 java 业务需求信息（ https://jisubang.com/q-2601.html ），结合楼主现在还在搞代码，很难不让人怀疑这个 qq 号他现在还在使用。

希望我的推测是错误的，不过另外一点楼主不管是在 v 站发帖求 star 还是其他平台账号命名风格（各种 ks_xxx 或者 xxx@douyin ），个人觉得都充斥着强烈的宣传自我为自己引流的目的性，很难让人想象这是一个 14 岁初中生的做事风格。

不过不管怎么样，希望用心写代码是楼主现在的真心选择，祝楼主年少有为，不负韶华。

1 2 3 4 5 6 7 8 9 10 ... 12

❮

❯