V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  passerbytiny  ›  全部回复第 70 页 / 共 153 页
回复总数  3054
1 ... 66  67  68  69  70  71  72  73  74  75 ... 153  
2019-07-10 11:06:20 +08:00
回复了 XiLemon 创建的主题 宽带症候群 OneDrive 客户端是被 Q 了吗
貌似 Q 升级了,能 ping 通,但是只要一有真实连接(包括 SSH 登录),立马 ping 不通。
2019-07-10 10:58:52 +08:00
回复了 XiLemon 创建的主题 宽带症候群 OneDrive 客户端是被 Q 了吗
建议这几天冬眠,昨天用 Proxifier 改全局救急,今天 IP 被 BAN 了。
也有可能是公司虽在上升,但老板的老婆仍然看不起他。

突然严格的话,就算没走下坡路,至少在老板的心里是没走上坡路的。一直严格的话,大概率你们公司有“行政”,正好我刚发了一篇关于“行政”的主题,感兴趣的去投一下票。
对此感觉强烈反对的,建议感谢此回复。

@livid 主题真得很需要增加投票功能。或者社区需要可以被主题关联的独立投票区域。
2019-07-09 08:55:00 +08:00
回复了 crystal1992 创建的主题 酷工作 问问各位 hr 同学,统招 211 计算机结业你们会直接 pass 吗
猎头 100% pass,有招聘额度限制的公司的 HR,在不是新部门集中招聘的时候,很有可能 pass。除了上面的情况,你四年工作经验绝对让人忽略你的学历。
@mywaiting
@iiduce
我原本不知道他们一面倒的评价是不是有用,知道看到了你们的回复,我知道了,他们是对的。
2019-07-05 14:57:11 +08:00
回复了 springmarker 创建的主题 程序员 在微服务中是用队列好还是 RPC 好
@springmarker #112 举个例子。
生产者:1 分 0 秒发送消息一,张三把自己的性别改成女; 1 分 10 秒发送消息二,张三反悔了,把性别改回男。
消费者一,1 分 0 秒收到消息一,因为线程阻塞,1 分 15 秒才开始执行,1 分 17 秒执行完成。
消费者二,1 分 10 秒收到消息二,立刻执行,1 分 12 秒执行完成,数据已同步保存到数据库。
最终的结果是,虽然先改女后改男,消息也是顺序接受的,但执行顺序是先改男后改女,执行顺序与发出顺序不一样。

我大致浏览了第一页的回复,发现你的回复一直是高姿态的回复,翻页之后也没有变化。这种情况虽然没什么不对,但是我已经没有继续讨论的积极性了。
2019-07-05 14:30:21 +08:00
回复了 springmarker 创建的主题 程序员 在微服务中是用队列好还是 RPC 好
@springmarker #111 通过上游抢任务来分配请求到上游的负载均衡网关,我至今没见到过,你需要例子来证明你说的话。第三点你已经在胡扯了,我猜想你所说的只需面对中间件,指的是生产者只需要知道中间件端口就去发送消息,而不去管发啥内容,不去管有没有消费者。生产者制定消息内容,不比选择哪个 RPC Server 更简单;生产者本身不需要管有没有消费者,但是要有额外的监控中心去管,而负责任的生产者,是应当预判消费者不存在而增加自动重发机制的。
2019-07-05 13:51:20 +08:00
回复了 springmarker 创建的主题 程序员 在微服务中是用队列好还是 RPC 好
因为回复太多,我就没看。看了楼主的追加,貌似也没提到核心问题。
针对楼主的优点,纠正一下:
1.消息可以堆积,只要队列稳定,消息丢失的概率就比直接 RPC 低。
——想要让队列稳定,不是很难,是相当相当困难:队列只能保证先进先出,但不能保证先出就先消费,先消费就先执行,****队列无法顺序执行这一个缺点,就能让你永远优先选择 RPC 而不是消息队列****;除了 Kafka 外,很少有消息中间件能保证不丢失,RabbitMQ 要是只有生产者和交换器而没有消费者,发出去的消息直接丢失,通常来说,生产者宿主服务要在发送消息前提前备份消息,用以在消息丢失后重发,消费者要处理排除重复发送的干扰;除非是 RPC 方式的消息,发出去的消息只允许接受或丢失,不允许抛出异常,业务上失败时消费者只能记录失败然后追加补偿措施以实现最终一致性。
2.由接收端主动获取消息的话,负载就由接收端控制了,不会像 RPC 一样无法均衡的负载。
—— RPC 照样可以做负载均衡,两者的负载均衡也并无多大区别,这个不能算优点。
3.没有类似 Zookeeper 的注册中心,发送端和接收端只要面对队列就可以,发送端不用同时面对注册中心和多个接收端。
——虽然没有 Zookeeper,但是需要消息中间件呀(早期 Kafka 版本,还需要同时面向 Zookeeper 和 Kafka ),复杂型只高不低。
2019-07-05 09:15:58 +08:00
回复了 nananqujava 创建的主题 职场话题 事情终于发生在我身上了, 这种情况我可以申请 N+1 吗
@lagoon #70 除了第一点之外,后面的全对。你说的这情况在早些年的反贪电视剧上经常见,“人人都贪,我不贪他们就要弄我,所以我只能偶尔贪一次”,说这话的人,要么立功后扑死,要么立刻领便当。不是所有的时候都法不责众的,抓不到典型才不责,抓到了典型就死则典型。
做过一小段时间对日外包,日本人重过程到变态,比如代码要逐行评审,比如单元测试把每一个步骤都截图出来供人评审。然而他们却不知道(也有可能是刻意忽略)过程的目的是控制成本和保证结果,所以导致成本暴涨(当然要是没有这个原因也不会有中国的对日外包行业)、过程僵化、结果严重偏离……。
2019-07-04 17:36:37 +08:00
回复了 nananqujava 创建的主题 职场话题 事情终于发生在我身上了, 这种情况我可以申请 N+1 吗
实锤虚拟打卡的话,N+1 是不可能了,劳动仲裁也不可能对你有利。但是如果你有精力,并且——这是重点——愿意承担“跟公司较真”的风险的话,可以找律师跟公司谈和解。和解若成功,公司补偿你一部分钱,公司承诺永不追究及永不透漏你虚假打卡的事实,你承诺永不追究加班费和社保。和解若失败,闹上法庭结果不确定,但以后是肯定没公司会要你了。
2019-07-04 13:04:25 +08:00
回复了 nananqujava 创建的主题 职场话题 事情终于发生在我身上了, 这种情况我可以申请 N+1 吗
是我出现幻觉了,还是 V2 出现 bug 了,怎么感觉半年前见过一摸一样的贴子
以我看过的几本书(实现领域驱动设计、硝烟中的 Scrum 和 XP、数据仓库工具箱)的经验来说,书,哪怕是教程性质的书,其目的是全面总结经验或带你入门一种技术,所以只会举例而不会放实际的例子(实例会限制你的思想),或者说,只会告诉你应该怎么用,而不会告诉你怎么用。
2019-07-03 16:53:23 +08:00
回复了 decruzzhang 创建的主题 职场话题 面试官给了口头 offer,结果又不要我了
很有可能:你的面试官是初次面试(或者也只是接到了他上面人的口头允许),以为过了他就可以发 offer 了,然后他在人事那里被批斗了。
2019-07-03 16:46:28 +08:00
回复了 auto 创建的主题 Redis 请教一下,各位大佬公司里用 redis 作分布式锁的多吗?
还没用过分布式锁。以后除非老项目,也遇不到分布式锁了,现在被教育优先采用最终一致性。
2019-07-03 09:44:47 +08:00
回复了 npe 创建的主题 问与答 合同到期,不准备续签,可以直接跑路吗?
@tilv37 #12 合格的 HR,你光口头说说是不行的,会追着你要书面回答或者离职申请。因为你要是最后耍赖不承认口头答应,就要 n+1 了(公司也可以选择续签,然而那就变成 m 年+n+m+1 )了。
2019-07-03 09:37:56 +08:00
回复了 firhome 创建的主题 程序员 QQ 老被拉讨论组怎么办?
你要是类比,老被家长拉去相亲怎么办,还可以继续讨论。你要是类比,老被陌生人拉去相亲怎么办,请自觉删库跑路。
2019-07-03 08:43:48 +08:00
回复了 npe 创建的主题 问与答 合同到期,不准备续签,可以直接跑路吗?
@delectate #9 瞎胡说,合同不会自动续签,但 hr 要是没提前一个月找你,劳动关系自动存续,工资照样得发,解雇照样需要提前 1 个月通知。
1 ... 66  67  68  69  70  71  72  73  74  75 ... 153  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5968 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 48ms · UTC 02:33 · PVG 10:33 · LAX 18:33 · JFK 21:33
Developed with CodeLauncher
♥ Do have faith in what you're doing.