Tallate

该吃吃该喝喝 啥事别往心里搁

发表于 更新于 分类于

分库分表

MySQL单表最多只能存储千万级别的数据，当然如果表里有大字段，可能存储的量级会低一些。
当业务规模增长，数据量可能会上升到单表无法存储的情况，就需要将数据分散到多张表。

  • 按一定规则hash数据，比如按user_id分库分表，就需要用user_id计算一个hash值，对应到一张分表；

如果hash得不均匀，可能会引起数据倾斜，比如某些特殊user_id的数据量特别大扎堆到了一个分库里，那么该分库的容量和水位都会比其他的更高一些。

  • 解决1：扩库，将原来16库、1024表细分成更多，数据会被打得更散；
  • 解决2：二级分表键，除了user_id，再找一个业务的分表键，且它需要足够的区分度。

发表于 更新于

设计一个AI生活管家，我们首先需要考虑其核心功能、交互方式、个性化设置、数据安全与隐私保护等方面。以下是一个基本的设计框架：

  1. 核心功能模块

  • 日程管理：自动同步用户的日历，提醒会议、生日、纪念日等重要事件，并能根据交通状况调整提醒时间。

    支小宝 豆包
    触屏界面 支小宝_3

  • 健康管理：记录用户的饮食、运动、睡眠情况，提供健康建议和饮食计划。可连接智能穿戴设备，实时监测生理指标。
    暂无

  • 智能家居控制：集成控制家中的智能设备，如灯光、空调、音响等，根据用户习惯或环境自动调节家居环境。
    暂无

  • 购物助手：根据用户偏好和需求，智能推荐商品，管理家庭库存，自动下单购买日常用品。

    支小宝 豆包
    触屏界面 支小宝_4

  • 信息查询与服务预订：包括天气预报、新闻摘要、餐厅预订、电影票购买、旅行规划等。

  • 学习与娱乐：推荐个性化学习资源，如在线课程、书籍；根据用户喜好播放音乐、推荐电影/电视剧。

  • 安全监控：与家庭安防系统联动，提供异常情况报警，如火灾、入侵等。

  1. 交互方式

  • 语音交互：支持自然语言处理，通过语音指令进行操作，提高便捷性。

  • 触屏界面：在智能终端上提供直观的图形界面，方便用户手动操作和查看详细信息。

    支小宝 豆包
    触屏界面 支小宝_1 支小宝_2 1、手输指令；2、快捷口令；

  • 移动应用：开发配套的手机应用，实现远程控制和信息同步。

  • 智能穿戴设备集成：通过手表、手环等设备接收通知和简单操作。

  1. 个性化设置
  • 用户画像建立：通过机器学习分析用户行为和偏好，不断优化服务个性化。
    支小宝_5
  • 自定义唤醒词：允许用户设置个性化的唤醒词，增强互动体验。
  • 界面主题与声音选择：提供多种界面风格和语音选项，满足不同用户审美。
  1. 数据安全与隐私保护
  • 加密传输：确保所有数据传输过程采用加密技术，防止数据泄露。
  • 隐私设置：允许用户自定义数据分享范围，严格遵守数据最小化原则。
  • 透明度报告：定期向用户报告数据使用情况，增加信任度。
  • 用户授权管理：对涉及个人隐私的功能，实行明确的用户授权机制。
  1. 持续学习与反馈
  • 机器学习算法：不断通过用户反馈和行为数据优化算法，提升服务精准度和满意度。
  • 用户反馈系统：建立便捷的反馈渠道，鼓励用户提出意见和建议，快速响应并改进。
    综上所述，一个全面的AI生活管家应是高度个性化、智能化且注重用户隐私的综合服务平台，旨在通过无缝整合各类生活场景，为用户提供便捷、高效的生活辅助。

发表于 分类于

keylen的计算

explain结果中，keylen表示使用的索引长度，是以字节为单位。根据这个值，就可以判断索引使用情况，特别在使用联合索引的时候，判断有多少的索引字段能被查询用到。

各类型占用的字节空间大小如下（5.6.4以后版本）：
DATE: 3
TIME: 3
DATETIME: 8
TIMESTAMP: 4
YEAR: 1
FLOAT: 4
DOUBLE: 8
DDECIMAL: 小数点前后分开存储，且以9位数为1组，用4个字节保存，如果低于9位数，则需要的字节数如下：

0 = 0, 1-2 = 1, 3-4 = 2, 5-6 = 3, 7-9 = 4

索引定义：idx_orgid_workspaceid_pid_pos
其中：
orgid: varchar(64)
workspaceid: bigint(20) unsigned
pid: bigint(20) unsigned
pos: decimal(20, 4)

最后得到keylen为284 = (64 * 4 + 2) + 8 + 8 + (4 + 4 + 2)

发表于 更新于 分类于

读扩散和写扩散

以一个微博发布场景来说
读扩散：内容发布者发布内容时，先存入自己的发件箱内，当粉丝来阅读时系统首先拿到粉丝关注的所有人，然后遍历所有发布者的发件箱，取出他们所发布的帖子，然后一句发布时间排序，展示给阅读者。
好处：底层存储简单，没有空间浪费。
坏处：每次读操作会非常重，操作非常多；而且分页不大方便。

写扩散：发布者发布一篇帖子时，遍历发布者的所有粉丝，给这些粉丝的收件箱也投放一份相同内容，这样阅读者来读feed流是，直接从自己的收件箱读取即可。
好处：通过数据冗余，提升了阅读者的用户体验。
坏处：对粉丝数特别大的情况不可行，特别是写扩散是异步操作，写得太慢会导致帖子发出去半天，很多粉丝依然看不见，体验也不大好。

读写混合

以微博为例

  • 当大V发帖时，提取他粉丝中比较活跃的那一批（这样可以筛掉大部分人），将大V的帖子写入他们的收件箱；对不活跃的那批人，采用读扩散的方式，一方面需要读取他的收件箱，另一方面需要遍历他所关注的大V用户的发件箱提取帖子，然后做下聚合展示。
  • 当一个粉丝量很小的人发帖时，采用写扩散方式，遍历其所有粉丝并写入粉丝收件箱。

发表于 更新于 分类于

领域模型

  1. 构建领域模型
  2. 从业务描述提取对象及关系（继承、关联、包含等），类似类图
  3. 写下来的领域模型，可以澄清不同参与者的内心假设，发现潜在的概念冲突和不一致的地方
  4. 用共同的价值来推动
  5. 业务规则 -> 业务场景 -> 业务目标
  6. 需求评审期间记录概念
  7. 用领域模型来指导实现
  8. 领域模型图类似类图，可以直接转换为类
  9. 实体对象 - 值对象 - 领域事件 - 领域服务
  10. 聚合 - 是业务逻辑的边界，根是业务逻辑唯一对外暴露的接口，比如要访问采购项，必须访问采购请求
  11. 子域 - 比如文档内可以发表评论，评论内部又可以划分为可评论资源、评论 、评论者，子域用于分解问题

实体

实标对象（Moment-Interval）：随着时间的改变，该对象会发生变化，比如采购计划。它的变化往往代表着关键业务的转移，比如被审批、被提交、入库等等。比起他对象更值得关注。在DDD模型中被称为实体对象。
实体——和业务紧密相关

  • 有状态
  • 基于标识唯一识别一个对象
  • 实体状态（属性）的变化不会影响到对象的识别（可以对比采购单和采购项来理解，一个采购单不会因为状态改变了就不再是那个采购单了，但是采购单中的一个采购项如果变化了，它没必要还是原来的采购项，可以是多个）

值对象

值对象本身是无状态的，不可变，没有唯一标识，从这个层面上来讲，值对象可以理解为实际的Entity对象的一个属性的结合，该值对象附属在一个实际的实体对象上面。值对象本省不存在一个独立的生命周期，也一般不会产生独立的行为。

领域服务

订单生成策略、供应商选择策略。建一个单独的对象，而不要挂在一个毫无关系的对象上。

领域事件

采购计划被创建，这种代表一种业务事实发生的东西统称为领域事件。也需要显式的建模在领域模型中。

聚合

聚合是业务逻辑的边界。突破逻辑边界对内部对象进行操作，会破坏业务逻辑的完整性。
解决方案：所有对聚合的更新都应该通过聚合根来进行。

  • 外部对象不允许直接访问聚合的内部实体
  • 在聚合边界内，对象之间可以相互引用。但是根是聚合中唯一允许被外部引用的元素
    联想老师提到的采购计划和采购项来理解，区分领域层和业务层。

发表于 更新于 分类于

深分页存在的问题

1
2
3
select *
from tname
limit 1000000, 10

当limit偏移量很大，MySQL就需要扫描大量数据才能找到指定页的数据，limit越大，查询耗时就越久。

还有一个问题：当 order by 排序字段存在重复值，那么在分页查询中可能会出现重复数据的情况。为了避免这种情况，可以在SQL查询语句中使用唯一的排序字段来进行排序，或者在SQL查询语句中增加一个唯一的排序条件，例如使用id字段进行排序，这样可以确保每条记录在排序后都是唯一的。

解决方案

  1. SQL优化 - 子查询 + 索引
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    -- 优化前
    select *
    from tname
    limit 1000000, 10

    -- 优化后
    select a.*
    from tname a
    inner join (
        select id
        from tname
        order by create_time desc
        limit 1000000, 10
    ) b on a.id = b.id;
  • 注意其中create_time字段需要加索引，否则需要排序的数据量一大就容易触发filesort。
  • 如果排序有多个字段，需要加上联合索引

  1. SQL优化 - where id > x
    将上一页的查询结果中的最大id作为下一页查询的where条件，这样可以大幅减少扫描行数，提高查询性能。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    select a.*
    from tname a
    inner join (
        select id
        from tname
        where status = 0
        and id > #{id}
        order by create_time desc
        limit 10
    ) b on a.id = b.id;

  2. 业务限制
    只允许查询指定时间范围内的数据。

  3. 限制最大页码数

发表于 更新于 分类于

很有可能考到的：层次式架构、大数据架构

摘要模板（时间+项目+项目简介+投入+历时+成功交付客户好评）
摘要：我所在的单位是国内某商业公司之一，作为主要技术骨干，2022年3月，我参与了某民营企业的文档知识库项目的开发。该系统对安全性、可靠性、可用性和响应速度要求很高，我选择了三层B/S结构作为该系统的软件体系结构，在详细的设计三层结构的过程中，我采用了浏览器作为表示层，Java Tomcat服务器作为中间层，MySQL作为数据库层，并采用了Redis缓存业务数据，来解决设计中遇到的性能问题，保证了知识库系统按计划完成并顺利投产，我设计的软件三层结构得到了同事和领导的一致认同和称赞。但是，我也看到在三层结构设计中存在一些不足之处：比如中间层的负载均衡算法过于简单，容易造成系统负荷不均衡。《补充下不足之处》
// 该系统包括协同引擎、企业文件系统、知识库三大功能模块，能够。该项目总投入382万元人民币，历时7个月，于2022年10月正式交付运行至今，受到了客户的一致好评。本文结合笔者的实际工作经验就该项目的《待定根据不同论文题目去简要概括本文内容》。

项目背景模板（为什么做+项目功能和技术介绍+过渡）
在企业内部协同工作过程中，。。。《补充背景描述》
// 该项目总投入382万元人民币，建设周期从2022年3月1日至2022年10月31日止历时7个月。系统采用40台4核8G内存60G磁盘空间的虚拟机搭载软件的运行，考虑到对于性能及可扩展性方面的要求，使用Nginx正向代理网络请求，将请求转发到服务端的业务集群，并通过服务发现等机制实现云主机的弹性扩容能力。项目的主要建设内容包括三大模块：一、协同引擎，完成对文档多人协同编辑的状态维护；二、企业文件系统，完成对文档的元数据的维护；三、知识库模块，为用户提供友好的知识管理界面《补充下》。
笔者所在的公司虽然在。。。《过渡》

正文
我所在的公司于2021年3月正式启动该项目的建设工作，我作为项目组内的主要技术骨干之一，主持并参与了文档知识库系统的项目计划、需求分析、设计、编码和测试阶段的工作。
由于系统面向的客户不少是国内大型组织，因此系统对安全性、可靠性、可用性和响应速度的要求很高，我选择了三层B/S结构作为该系统的软件体系结构，下面，我将分层次详细介绍三层B/S软件系统结构的设计过程。

  1. 表示层为浏览器。《补充》
  2. 中间层为Java Tomcat服务器《补充》
  3. 数据层为MySQL服务器。因为MySQL在处理事务方面安全且性能满足诉求，我司一直使用MySQL作为事务处理的数据库，并取得了很大的成功，有独特的一套数据库中间件体系，在MySQL数据库的使用方面积累了自己独到的经验和大量的人才，为了延续技术的连续性和保护原有投资，我选择了MySQL作为数据层。
    但是，在设计的过程中我也遇到了一些困难，我主要采取了以下的办法来解决：

项目总结模板（强调项目顺利交付运行反馈好）
由于我软件三层结构设计得当，并采取了有效的措施去解决设计中遇到的问题，文档知识库系统最后按照计划完成并顺利投产，不但保证了系统开放性、可用性和互用性，取得了良好的社会效益和经济效益，而且我的软件三层结构设计得到了同事和领导的一致认同与称赞，为我司以后系统的开发打下了良好的基础。
在总结经验的同时，我也看到了我在软件三层结构设计中的不足之处：《补充下不足之处》
// 经过近7个月的项目开发，该文档助战项目顺利投入使用，协助客户对企业资料进行全面的管理及协同，运行至今客户反馈良好。该系统由于保密性高，性能要求高，技术实现难度高，项目建设周期长等原因，建设过程困难重重。但由于笔者及项目团队成员十分重视项目的。。。《回应论文题目》，最终保证了该项目按质按量顺利交付。
// 当然，在本项目中，还有一些不足之处，比如：。。。《小问题、不是什么大问题》不过，经过我后期的纠偏，并没有对项目产生什么影响。在后续的学习和工作中，我将不断的充电学习，和同行进行交流，提升自己的专业技术水平，更好的完成系统架构设计的工作。

发表于 更新于 分类于

限流涉及的组件间关系
组件间关联关系

应用服务（基于JVM）稳定性

方案

  1. 降低系统水位

Redis稳定性

MetaQ稳定性

DB稳定性

  • 稳定性
    • 基本原则
      • 分布式：压力分散，区别于单体式
      • 异步化：非核心功能异步化，提升吞吐率（单位时间可以处理的请求数）
      • 简单安全：避免使用未经严格验证的公共代码、库、二方包（同组织）和三方包（组织外部）
      • 数据一致：最终一致性保障，幂等、可重入
    • 稳定性措施
      • MQ稳定性
        • 消费监控，流量突增容易
      • 缓存稳定性
      • 流控
        • 流量预估、流量流向分析
        • 扩散比：每一笔请求对下游形成多少次调用
        • 峰值、热点分析
        • 限流
          • 多维度多举措做好限流，把流量控制在系统可承载范围内，系统就不会进入完全不可用的状态；限流可以减少诸如热点、超时、慢SQL、外部依赖、系统容量不足等问题。
          • 前端限流：单用户单端登录限流
          • 网关限流：Nginx
          • 服务限流：Sentinel，支持集群限流，但是集群限流因为需要一个中心DB存取流量值，所以性能会差很多，不适合特别高并发的场景
          • 单机限流：线程池 + Guava RateLimiter（令牌桶）
        • 预留Buffer
      • 依赖管理
        • 强弱依赖识别
        • 强弱依赖模拟演练
      • 预案
        • 预案类型
          • 业务降级
          • 限流
          • 系统故障（容灾）
            • 存储故障
            • 中间件故障
        • 预案执行时机
          • 自动切换
            • follow技术方案设计，比如成功率低于60%切换到备库
          • 提前预案
            • 业务降级，比如大促前为了应对将来的暴涨流量，将非核心业务降级
          • 紧急预案
            • 业务有损降级，保命用
        • 故障演练
      • 监控
        • 日志规范
          • 请求上游、RPC/MQ/DB请求源头、请求用户标识等
        • 系统监控
          • 机器健康状态、应用健康状态
        • 流量监控
          • 入口流量、服务调用流量、错误流量等，注意监控流量突增
        • 业务监控、数据大盘
          • 业务数据总量、分类统计等
          • 一致性问题监控
      • 备份
      • 测试体系
        • 功能回归
        • 全链路压测
        • 日常压测和极限压测
      • 数据一致性
        • 最终一致性
        • 方法
          • 业务实时对账
          • 离线对账
          • 手工或自动化数据校正
阅读全文 »

发表于 更新于 分类于

摘自：https://cloud.tencent.com/edu/learning/live-3682

  • 汇报
    • 为什么汇报
      • 沟通手段而不是目的
    • 汇报类型
      • 请示型：请示和领导针对某问题的交流
      • 过程型：让领导了解一个项目或事情的进展
      • 研讨型：让领导或一些相关人针对某类问题进行研讨
      • 审批型：针对即将进行的行动进行汇报，从而获得审批通过
    • 汇报的核心要素
      • 目的：通过汇报达成一个目标，汇报本身不是一个目的、而是一个沟通手段
      • 内容：事情
        • 问题定位清晰
        • 方案阐述清晰
        • 差异化突出，和其他方案、竞对的优势
        • 收益可度量
      • 逻辑：逻辑顺畅
        • 通过严密的推导证明所选的方案是符合要求的、最优的
      • 呈现：呈现清晰，观点明确
        • 简单易懂，将重要观点着重标识和强调，观点之间要有关联关系，让人容易抓住重点
      • 问答：汇报最后的问答环节
    • 汇报的步骤
      • 汇报前
        • 对齐目标：开头标明背景和目标，结尾列好汇报后的行动计划（行动内容、负责人、时间）
        • 准备内容
          • 逻辑清晰，按金字塔结构组织内容，形成一个结构化的目录
          • 重点突出，先讲结论再讲过程（节约时间提升效率，跟着领导关心的问题来做解释）
          • 简洁易懂，少即是多
        • 问答预案，准备可能的问题和答案
      • 汇报中：声音，节奏（详略得当）
      • 汇报后：纪要明确，落实跟进
        • 汇报结束的时候，第一时间对会议纪要进行核实，确定自己的理解和最重要的内容、行动能落实。

发表于 更新于 分类于
  • 辩论
    • 你不需要回答每个问题
      • 如果对方问什么就答什么，就会容易掉进对方挖好的坑里
    • 把讨论转移到对自己有利的话题
      • 转移话题
      • 反问
    • 不要去证明自己，而是要表达自己的观点
0%