V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  berg223  ›  全部回复第 1 页 / 共 2 页
回复总数  40
1  2  
6 天前
回复了 plko345 创建的主题 程序员 请教两个线上问题该怎么做好
1. 从你的描述来看,应该还没搞清楚瓶颈在哪,瓶颈可能是磁盘,网络,内存,肯定不是 cpu 。我认为在没有找到问题根本原因之前提出的方案就是扯淡,包括无脑加机器这个方案。我不理解你的友军为什么会不同意你提高实例并发这个建议,我认为他们不够专业。
考虑现实意义,格口更大的柜子装 1 立方米的平均成本是否一定比格口小的成本低呢
44 天前
回复了 berg223 创建的主题 奇思妙想 抖音推广软件如何减小被风控概率?
@milukun 多谢,我打算先简单尝试一下,如果风控真的很严的话,花点钱也不是不可以,就是钱多少的问题,有花钱少的办法吗。
45 天前
回复了 berg223 创建的主题 奇思妙想 抖音推广软件如何减小被风控概率?
其实我只是想推广,而不是想整个推广的产品出来给别人用,所以我不需要去搞脱壳用户登录验证那些东西,甚至可以用类似按键精灵的方式来模拟操作,有很多这种客户端自动化测试工具的,另外还有抖音网页版,不一定非要搞客户端,总而言之,我不担心实现上成本很高。我担心的点主要是在法律风险和风控这里。
45 天前
回复了 berg223 创建的主题 奇思妙想 抖音推广软件如何减小被风控概率?
@zhouquanbest 简单估算了一下,假设每个大学生每天给他们 100 块,他们每天工作 8 小时,按照 20 秒一个评论来算,这样一天下来相当于代码的效率,就是说我的成本是找 8 个学生给我刷 3 个月的单,每天给他们 100 块,总共是两万四千元,不过这个办法的好处是可以通过雇更多人同时干这个事来提高效率。
45 天前
回复了 berg223 创建的主题 奇思妙想 抖音推广软件如何减小被风控概率?
@monkeydev 这样看发评论是个好办法,能分享一下有什么要注意的吗,比如频率,另外抖音对这种做法的态度是什么样的,没有受到来自官方的阻碍吗?
45 天前
回复了 berg223 创建的主题 奇思妙想 抖音推广软件如何减小被风控概率?
@westoy 谢谢,你说的是 dou+推广这个办法阿……
45 天前
回复了 berg223 创建的主题 奇思妙想 抖音推广软件如何减小被风控概率?
@westoy 氪金不违法的途径有吗,这个是违法的吗?
光在不同介质中速度是不一样的
像头条这种是着眼于通过推荐算法通过产生更多的水,从而产生成本优势。另外,这类中心化平台将产品收入分成给创作者,增加了系统参与的角色,增加了维度,是一种降维打击。所以商业模式上能否增加维度呢?
@sNullp 使用十万个为什么的方式来思考,顺便整理下学到的。为什么博客衰落了?因为同样的内容,博主的流量相比后来者的流量要少,出于盈利目的的博主就转型了。为什么同样的内容博主的流量没有后来者的流量多呢?因为后者有很大的读者用户基础,信息是灌输给用户的,而博客则是用户主动去搜索的,人性就是偏向于懒的一面,所以抓住了这部分用户,事实证明这部分用户规模是相当大的。为什么 google reader 这样的阅读器,将去中心化的内容灌输给用户却没有成功呢?楼上有兄弟说了是因为这款产品没有商业模式。为什么 google reader 这样的阅读器不能用广告来营收,但是后来者却可以用广告来营收呢?目前看来这个系统运行起来需要三种角色,读者,内容创作者,产品开发者,任何一方不能从中获利,都会阻碍系统的运行。内容创作者的盈利方式是对产品获得的收入进行分成,产品开发者获得的收入也是产品的收入分成,产品开发者可以做高级功能收费,也可以类比成他有自己单独的水池,这两种角色共享了产品的收入,只有读者的获利方式不是钱而是信息,读者就像水龙头,而产品收入就像水池里面的水,内容创作者和产品开发者就像出水的阀门。只要水龙头出的水够多,内容创作者和产品开发者就不愁没钱赚。回到 google reader 为什么不能盈利?假设用信息灌输的方式可以解决水龙头出水不够多的问题,但是另一个环节出了问题,这款产品的收入没有分成给内容创作者,而内容创作者的积极性则被中心化平台调动起来,产品留不住内容创作者导致失败。那么是否可以做一个去中心化的系统,这个系统可以平衡各种角色间的利益关系呢?问题又来了,如果这个系统不能产生成本优势,只是让各方保持现在的营收水平,产品真的会有竞争力吗?
简单了解过区块链技术的实现,由于技术深度不够,所以只能简单聊聊将去中心化这种思想而不是技术。具体点,怎样去做一个去中心化的博客系统?首先我们可以看看现在中心化的系统是是什么样的,存在哪些中心化的弊端?举个例子,假设将今日头条的创作者看作未来去中心化系统的潜在用户。目前这部分用户之所以愿意在平台上创作内容,与其会获得创作奖励有很大关系,再直白点,创作者的内容创造了价值,这部分价值会转换成平台的广告收入,因为今日头条要运营这样一个平台有各种成本在,但是这部分广告收入有一定比例是让平台拿走了,这个比例是多少也是平台说了算。技术的本质是在于提高生产力来降低生产成本,如果去中心化技术能够降低这个成本,那么无疑是能颠覆当前的形式的,我认为这应该是要考虑的入手点(利用去中心化技术产生的生产成本优势,给创作用户更高比例的抽成)。具体到技术实现上,目前去中心化技术聚焦到了区块链上,一方面来说区块链技术不成熟,安全隐患还是比较严重,另一方面,区块链这门技术拿来做数字货币还行,拿来搞博客系统的话,据我所知目前我们使用编程语言编写的网站是无法运行在链上的,也就是说无法降低中心化系统的服务器成本和运维成本,另外,中心化系统的主要成本是人力成本,似乎目前的去中心化技术也降低不了这块的成本对吧?所以现在谈”复兴“,可能还是太早了一些。
77 天前
回复了 frank1256 创建的主题 程序员 想起几年前刚毕业有一道面试题。
@berg223 还是不对,字符串常量是在堆中的,只有字面量才会在常量池中,所以应该注意的不应该是常量池的大小。
77 天前
回复了 frank1256 创建的主题 程序员 想起几年前刚毕业有一道面试题。
@berg223 回头看了下直接拼接成字符串往磁盘上怼应该是有问题的,需要把 jvm 的常量池设置大一些。。
77 天前
回复了 frank1256 创建的主题 程序员 想起几年前刚毕业有一道面试题。
@berg223 更正下,事实上这块的 io 应该是 ms 级别的更正为 “事实上这块的 io 的优化空间应该是 ms 级别的”。
77 天前
回复了 frank1256 创建的主题 程序员 想起几年前刚毕业有一道面试题。
假设一行数据有 50 个字段,每个字段 8 字节,一行占用 50*8=400B ,大约 2.5 分之一 KB ,50w 除以 2.5 大概 200MB ,数据量不算大,4g 内存大概是这个规模的 20 倍,不算大的,也就是说每个字段 8 字节,1000 个字段才会在内存上有瓶颈。瓶颈是在 io 上,假设数据是写到同一块机械硬盘上,仅考虑性能的话,在写的时候实际上都不需要并发和 nio 啥的,直接拼接成一个 csv 格式的字符串往硬盘上怼,最大化利用磁盘顺序写的特性,这样速度理论上应该最快。但是实际工作中考虑扩展性不应该这么干。事实上这块的 io 应该是 ms 级别的。
假设要读取的 mysql 数据是同一块硬盘,多线程也不一定比单线程快,因为瓶颈在于 io 上,读取的 io 分两类,一个是程序和 mysql 之间的网络连接,另一个是 mysql 读取磁盘的 io 。对于第二类肯定单线程比多线程快,对于第一类来说多连接应该比单连接要快,假设机房带宽是 100Mbps=12.5MB ,那么单连接传输 200MB 数据大概需要 200/12.5=16 秒,假设磁盘速度是 100MB/s 的话,单次读取所有数据就只需要 200/100=2 秒,加在一起就是 18 秒,开 x 个连接读取等量数据大概需要 16+2/x 秒,优化空间是秒级别的,最大优化空间不超过 2s ,当然不是 x 越大越好。
综上,这题最多优化 2s ,未优化前速度大概是 20s 左右,确实没多大优化空间。
2021-07-07 14:18:22 +08:00
回复了 baiyuxiong 创建的主题 信息安全 F**K,数据库被黑客删光了
2021-07-07 14:12:42 +08:00
回复了 baiyuxiong 创建的主题 信息安全 F**K,数据库被黑客删光了
不要慌,rm -rf 大概率是可以用软件恢复的
2021-01-07 00:45:53 +08:00
回复了 hello826 创建的主题 程序员 Java 线程数过高,如何排查
具体的讨论可以看一下: https://github.com/Kong/unirest-java/issues/140
2021-01-07 00:41:20 +08:00
回复了 hello826 创建的主题 程序员 Java 线程数过高,如何排查
其实堆栈信息已经很明确了,就是卡在了 SyncIdleConnectionMonitorThread 这个文件的 22 行,你看一下代码差不多能猜到原因了
1  2  
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2077 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 48ms · UTC 16:49 · PVG 00:49 · LAX 08:49 · JFK 11:49
Developed with CodeLauncher
♥ Do have faith in what you're doing.