@idragonet #22
只有粤语警察在乎别人口音问题

接触的层次决定吸烟比

不是说层次高不吸烟 层次高照样吸烟
但是层次高的人里面，不吸烟的比例会稍微增加一些
底层人士不吸烟的会非常罕见

非常合理

@1F357 #33
一样 找外部的也是 决策的背锅啊 你找的肯定跟你有关啊
目前最好结果就是直接张嘴就问 gpt

还是不建议这么跨舒适区干活
玩惯了 exception 那一套 改 go 推荐这一套 可能一年都改不过来
不如再找个 java 工作

@icelake #5
可能一个月都挣不到 2000 块钱的客服说话的逻辑性不要抱幻想。哪怕是卖几万显卡的也一堆这种照本宣科的客服

大概率这个说法的原因是，有很多人接显示器不好使，接大部分电视都好使

所以就总结出了这么个知识库

--------
没研究过这个问题，但是可以很容易的盲猜出来原因：

无外乎，这个红白机设备输出的信号，不符合显示器这个设备的输入信号要求，而符合很多电视的输入信号要求

不查手册，脑猜大概率盲猜 HDMI 的信号，里面可能会有以下格式参数（都是瞎猜的，不要上纲上线）

分辨率（像素长宽），逐行扫描/隔行扫描，刷新率



然后考虑到，他是一个 1980 年代的设备结构，大概率是加了一个协议转换芯片，把模拟视频信号转到了 HDMI 上面去跑

这个设备的原始输出的画质是很低的，所以很可能这个芯片是个低成本的上古芯片，直接渲染个 640*480 甚至更低的输出，这种芯片可能 2000 年就量产了，成本低廉

而你现在在用的液晶显示器，一般来说主要的场景是显卡输出给他的信号，能接到这个显示器上的设备，可能输出 800*600 的设备都很少，所以现在的液晶显示器可能都不会给自己的固件适配很低的分辨率，可能 800*600 就是最低能接受的了，而显示器本身也没有常态的低画质输入请求，不会做太离谱的输入画质的是适配缩放这类功能，浪费时间。

这样就会导致，这个红白机的输出的画质太低了，甚至不会在主流的液晶显示器，尤其是大面积的或者比较新的显示器的输入最低标准内。而显示器的用户群体，普遍是可以理解技术演进的，你说不支持，那就不支持吧。

而用一些上古液晶显示器，尤其是 17 寸方屏啥的，兴许就能支持。

这是“不支持显示器”的大概率原因

---------------------------
而“电视机” 这个客户群的画像，你是无法想象他们会接什么奇怪的设备的，而且电视机天生有模拟输入和上古输入格式，他们的图像处理系统本身就能处理低画质（输入可能是模拟信号本身线数就低，所以可能输入一个很低分辨率的数字信号也能处理），所以硬件解码芯片一体兼容了

----------------------------

基于以上的分析，我甚至可以大胆推测，对于很多高端的，2024 年以后生产的，超大分辨率的电视，尤其是小米这类后起之秀没有电视机历史包袱的厂家，可能直接砍了模拟输入，以及各种低分辨率输入，所以很多电视应该也不支持这个红白机。。。只能说电视大概率支持。。。


------------
基于上面的分析，还记得我 diss 客服的第一段话吗

再大胆推测一下，因为他们还是会收到电视机也不好用的反馈，而不要怀疑他们的逻辑性，啥都懂谁干客服，我猜这类商品，你问问客服，还会有以下可能性：

1. 写 4K 电视不支持，这样筛选一些高级电视，然后让你联系客服咨询到底支持不支持
2. 写太贵的的电视不支持，筛选一些
3. 整理一个常见电视的已知不兼容列表，给客服，比如小米 xxx 不支持，索尼 xxx 不支持

@1F357 #28
抽奖这玩意，界面酷炫不重要，没人在乎这个
大家真正在乎的是没有作弊，公平性。即使大家不好意思公开说，心里也是在意的
搞那些黑箱系统，决策用这个的，操作的，和领导们都是一身骚，即使不说，也是这样的

你就算审计代码，也有懂不懂代码的一说
最稳妥的就是丢给 gpt

建议的方案：
按顺序每个人拿一个号码的门票 在进门时候发 确保连续
号码建议从 100001 开始
然后截至抽奖时候 统计发了多少个号码

然后抽奖时候 笔记本直接投屏 随便连一个国产 AI 带上下文 context 的对话系统

直接输入：
我们现在有 100001 到 1xxxxx 个门票号码 请为我从中随机抽出 100 个不重复的号码作为三等奖

然后再输入：
请继续为我们抽出 50 个不重复的号码作为二等奖，注意不能与之前的三等奖重复

……
以此类推

轻量就是娱乐性的东西
说实话 就是国内这些厂商把东西做的傻子都能买还不会出啥大坑
都整成 aws/gcp 那么复杂 筛选一下用户知识水平就能耗很多

@vczyh #32
额 别把野鸡攻略当回事吧
你要是认定一种做法 什么地方都找得到跟你想法一样的人



@hetal #36
补充一下 我用的根本不是你给的 changlog 里说的 Read-Write splitting
那玩意指的是

[routing:bootstrap_rw_split]
destinations=metadata-cache://HB2DB161/?role=PRIMARY_AND_SECONDARY

而我用的只是指定连接 PRIMARY 还是 SENCODARY

因为 INNODB CLUSTER 是不保证一致性的，甚至可以说，高负载下他是一定不一致的。
冷数据才可以连 SENCODARY

而且 spilit 这玩意纯属娱乐功能 源代码写的一坨屎

----
从 8.3.0 到 8.4.4 router 基本就没修复过任何正经的 bug

我公司有 oracle 的商业支持(mysql) 不过是比较便宜的 已经不再续了
他们商业支持认为我们反馈的问题是在骗他们 是在 joking 然后就不管了
他们认为 router 能自己 exit 还没有日志是我们在骗他

他们给我们这个问题定的结论是： 我们没管理好服务器 被人登上去手动 service mysqlrouter stop 了

@hetal #36
内部操作？
你不指定，默认就所有读写操作都在 PRIMARY 上面 除非你指定 SPLIT 的入口

我们现在不考虑副本 最小的集群上是 1 个 PRIMARY4 个 SENCONARY ，最多的 1 个 PRIMARY 三十多个 SENCODARY 才能扛得住请求数
都扔给 PRIMARY 启动后 100 毫秒整个集群就死了

@vczyh #29
挂了就不用了啊 你的程序都不是分布式的 就没必要上这个

你没发现他们这个设计图都没给你做交叉吗

或者换句话说 router 是不应该挂的 只有 app 能挂

这也是我遇到的问题 这个 router 高负载下是真的不稳

@vczyh #27
额。你看看文档吧，你没理解 innodb cluster 的架构。


@hetal #26
随便找一个
256G 内存 3TB 左右存储空间 每日高峰综合负载 40%左右 日产生新行数约千万 删除也差不多这么多 写占比 78%
90%字段整数类型 索引充分 非 DDL 慢查询阈值 1 秒

[DEFAULT]
name=system
user=mysqlrouter
keyring_path=/var/lib/mysqlrouter/keyring-39-1
master_key_path=/etc/mysqlrouter/mysqlrouter-39-1.key
connect_timeout=3
read_timeout=45
dynamic_state=/var/lib/mysqlrouter/state-39-1.json
client_ssl_cert=/var/lib/mysqlrouter/router-cert-39-1.pem
client_ssl_key=/var/lib/mysqlrouter/router-key-39-1.pem
client_ssl_mode=PREFERRED
server_ssl_mode=PREFERRED
server_ssl_verify=DISABLED
unknown_config_option=error
max_idle_server_connections=240
router_require_enforce=1

[logger]
level=INFO

[metadata_cache:bootstrap]
cluster_type=gr
router_id=44
user=node-router-main-39-1
metadata_cluster=HB2DB39
ttl=0.5
auth_cache_ttl=-1
auth_cache_refresh_interval=2
use_gr_notifications=0

[routing:bootstrap_rw]
bind_address=127.0.0.1
bind_port=6446
socket=/run/mysqlrouter/mysql-39-1-main.sock
destinations=metadata-cache://HB2DB39/?role=PRIMARY
routing_strategy=first-available
protocol=classic

[routing:bootstrap_ro]
bind_address=127.0.0.1
bind_port=6447
socket=/run/mysqlrouter/mysql-39-1-ro.sock
destinations=metadata-cache://HB2DB39/?role=SECONDARY
routing_strategy=round-robin-with-fallback
protocol=classic


[http_server]


[rest_api]

@vczyh #19

router 前面为啥要挂 lb 啊
router 是跟 client 绑定的末端设施 他自身是分配的


@hetal #15
无任何日志 它自己根本不输出任何东西

router 的日志是我二十多年运维生涯见过的最干净的日志 跟没有日志没啥区别

包括但不仅限于 自己就 exit 了 日志里啥也没有
还有它跟 cluster 的通讯一切正常 keepalive 什么都正常发 然后对下面的应用就不提供服务了

还有它提供服务 socket 正常 tcp 就 connection refused 以及反过来

当然我们自己在 router 以外做了一些东西去解决这个事情 暂时影响不大了

----------
router 的版本，我们最开始跑这个集群时候 是 8.3 那时候第一个 lts 还没发布 我们每一个小版本都跟着滚动更新
现在是 8.4 lts 最新 lts 更新我们延迟两周就跟着滚动更新
这些问题在任何版本都是一样的发生
其实看了他们 router 代码 这玩意压根也没怎么更新过多少代码

我们现在从 router 以外的 app 侧做了很多处理
同时对 router 外挂了检测机制 基本 2 秒内解决 router 的故障

目前 router 的抽风频率大概是一个 6 个 backend 6 个 router 的系统 每 55 小时左右 大概就会有一只 router 莫名其妙进入一个随机的故障状态