大能猫__个人页

1，如何降低日常业务中断的风险，比如停机发布，单机故障等？高可用性能提高 2、如何提升应用服务的负载均衡能力？合理利用分布式部署，弹性扩缩容，例如Serverless产品

前几天刚好体验了“ComfyUI玩转 AI 黏土风格生图”，还是非常认可的。优势：1，使用门槛低，一键部署，方便使用；2，按量付费，可以很大程度上降低成本；3，运维方便，有专门的团队负责运维；4，易用性好，操作简单，界面清晰，可以根据页面提示选择需要修改的参数；反馈：文字图片识别准确度还是不够高，希望能改进。

我觉得任何事情都没有太绝对，二维码全球每天使用量达100多亿，还是有可能会被用完的。虽说，二维码的设计允许它在相对较小的空间内容纳大量信息，并通过数字“0”和“1”进行编码，使得计算机能够识别和解读其中的信息，他们是基于数学计算产生的，可能趋于无限；但是，随着科技的发展，迭代，世界人口的增长，如同，像电话号码或网络域名一样，最初设计的二维码，基于它的加密方式，设计空间大小，等等，可能也存在资源枯竭的时候，只是，多年之后，可能会出迭代出更优的版本呢，或出现更优于二维码的产品。凡是都没有绝对性，对于我们来说目前还不会面临二维码缺乏的迹象，但是我们还是得从自身做起，不要恶意去申请不必要的二维码。

要是以后可以与盲文创新结合，使盲人也能感受到大模型的魅力就好了

我觉得主要是【兼容性】：一次编写，多端运行；兼容大部分热门平台；通用的组件可以以镜像的形式部署在微信，支付宝等大流量平台。

AlchatOS ideaTALK 针对同一问题，AlchatOS与ideaTALK相比，AlchatOS响应时间更快一点，虽然ideaTALK回复的具体策略更多一点，但是AlchatOS的点更好一些，比如分库分表，实际场景是经常遇到的，魔搭之前有体验过，操作超级简单，响应速度很快，应用场景很广， OpenCompass目前没有实践过，如果要选择会首选魔搭。

以pg为例，前提确保pg客户端与服务端正常；连接器：通过postmaster监控建立连接请求，之后进入认证（账号，md5密码等）。解析器：对sql进行结构与语法等进行解析。优化器：经过pg_analyze_and_rewrite，orderby等方式检查后，生成执行计划（走单表还是全表扫描，走分区表还是用索引查询等）。执行器：sql真正执行之前，预检查，确定查询范围以及规则，如读请求，是在bufferpool里面读取还是磁盘读取。结果：sql响应结果返回给客户端。

有利有弊，利：可提升工作效率；弊：过度依赖，降低自身思考能力

事件驱动架构（EDA），作为一个经典架构模式，在云时代下再次流行是必然的趋势，由于早期的软硬件的成熟度是不够的，再加上技术的局限性，导致其应用不是很广泛，但是随着数字时代的发展，技术的成熟，事件驱动再次映入我们眼帘也是必然的结果，因为它是超低耦合，超高性能的一种架构； 随着技术的发展，22年服务架构已基本上全部进入云原生时代，并且随着微服务与云原生技术的变革，服务与服务之间的消息也慢慢趋向于驱动架构发展，因为事件驱动的优点也是越来越突出，比如，松耦合，可扩展性，异步处理消息，以及权责分离等。 相较于传统的消息处理，譬如消息的同步处理，一般需要client与service之间需要相同的存根，并且有合适的服务注册中心registry service才能实现同步传递，这样旧对厂商的兼容性有一定的要求，还有TCP的三次握手消息传递，都存在一定的局限性。 因此，随着技术的发展，微服务之间的消息传递会geng更倾向于事件驱动，它的低耦合，使得client与service之间不需要有相同的信息存根，而是通过代理broker将两者解耦，将同步消息转化为异步，只面向代理，也可以通过schema registry来控制上、下游数据的传输结构，此时就不需要上下游数据结构完全一致，只要通过代理能够解析数据即可，这样旧确保了数据的低耦合，从而减少数据之间的影响；当然，他的扩展性，灵活性，也是很有优势的，比如在一对多的事件，以及大业务场景涉及到增删功能时，事件处理器也可以在不影响其他元素，实体，事件或者组件的同时，并发更新，增删组件，并发处理； 虽然，事件驱动的优点很明显，但是也存在很多的缺点，比如，异步处理带来的代码复杂度，事件顺序的可保证性，上下游数据的准确性，事务处理错误时，如何准确的追踪，以及回滚，还有运维的复杂度，都具有很大的挑战性； 因此，对于未来发展的大方向来说，事件驱动的方向是毋庸置疑的，但是，它对于软件的成熟度要求也会高了，所以，我们需要跟深刻的研究与探索，希望未来的某一天事件驱动能够普遍化，能够更好的服务于人类。

人生处处有意外，何况产品？没有十全十美的人，也没有无bug的产品，只能尽力争取做到更完美的产品

1、数据库流行度排行榜会影响你的数据库选型吗？ 会的，高性能低成本的数据库，肯定是第一优先级选择项。 2、对于 PolarDB 的本次登顶，你认为关键因素是什么？ 高性能以及低成本polardb本来就有云原生的加持，必定有弹性扩缩容的能力；加之分布式，更能提高海量数据的处理，然后还有高可用功能，有效的提高了数据库的性能；还有新版本“三层分离”，更能体现出高性价比的能力 3、PolarDB“三层分离”新版本发布，对于开发者使用数据库有何影响？ “三层分离”主要是CPU,Memory，storage的分离，以往的数据库，cpu和memory往往是以统一的配比组成，这样必然会有一定的限制性，而三层分离，正好解决这种问题，将cpu，memory都以池化来体现，用户根据实际的业务场景，根据需求选择cpu和memory，这样不但可以提高效率还能大大降低成本；同样storage，以往的数据库可以是以实例节点的服务器存储作为集群存储，这样就往往会产生oom等问题，而storage的分离，是将存储池化，集群化，用户根据需求选择存储大小，而且收费自由，这样可以大大降低资源的浪费；所以说，“三层分离”对于开发者来说，也算是一个挑战，他会促使开发者更专业，更能开发出性能更好，成本更低的云原生数据库。

多培养点其他爱好，分散注意力，反正你干哪一行都会有工作压力和职业怠倦，多干点其他事，省的去想这些，除非你有明确的目标，哈哈哈。。。

阿里云数据库走向Serverless与AI驱动的一站式数据平台是未来的一个方向，并不是必然的结果；Serverless在处理数据库途观方面的又是是显而易见的，就拿polardb来说，对于用户或者阿里云运维人员来说，不可能把精力全放在数据库的托管上，也不可能在业务高峰期一味的去扩容，着不但提高了成本，也浪费了资源，而Serverless在这方面的作用是显而易见的，比如在高峰期，可以根据以往的经验设置一个峰值，当cpu高于这个峰值时，集群自动扩容，低谷时，也能自动缩容，这大大提高了成本，和资源利用率；再说AI，大数据的时代，AI的发展必然越来越快，毕竟他的成果也是很显著的，可以大大的提高工作效率，但是AI它太客观了，它职位根据人为导入的知识来回答用户问题，这就造成有时候回答问题并不标准，会出现牛头不对马尾的情况，而Serverless可以提高数据库的托管能力，当然也能提高数据准确度，这样两者结合必然时一个很好的效应；但是我们也不能一味的去依赖两者，因为人的像是可以主管+客观，可以因场景不同而给出更符合的方案，但是Serverless+AI它终将代理不了人工；所以说，阿里云数据库走向Serverless与AI驱动的一站式数据平台，它知识阿里云以后的一种选择，一个方向，但是它不是必然的结果，大数据时代，科技发展的速度之快，犹如惊鸿一瞥，可能未来还会出现更好的产品来代理Serverless+AI，我们期待吧！

以为是，实际是网络抖动

我觉得不能说是浪花，可以说是未来的航标之一。因为现在从事向量数据库厂商也是很多的，毕竟如今的大模型的热度是很强的，其实向量数据库的技术门槛不高，想将它独立细分的可能性是很小的，现有的数据库能力结合AI已经做的相当不错了，但是针对具体的业务场景，生产系统，他对数据库的实时性，准确性，规模性要求是很高的，AI虽然有他的又是，但有时候他的准确性并不是很高，往往是牛头不对马嘴，很容易误导用户，而向量数据库在这块是挺有优势的，未来我们使用向量数据库，结合AI，在数据的总结，分类，实时同步上面做出更准确地数据。当然也可以把他们结合起来打造一个新的镜像产品，一起部署到k8s上，去行业上输出更好的解决方案。所以说，向量数据库是未来的航标之一。

前面同事用python2写的脚本，领导让同步到python3，但有些必须2来跑，就兼容性踩过

家用电器哦

标准之一，不能作为唯一

1、你觉得 JAVA 中最晦涩的知识点是什么？多线程2、你为什么入坑 JAVA？工作需要

只能说重要部分之一