From d9290e497208af1b1338bee09f47a71e9c9180c1 Mon Sep 17 00:00:00 2001 From: muqiuhan Date: Wed, 19 Mar 2025 13:09:14 +0000 Subject: deploy: bc22b4eaeb6005d9af7f32e09dbb1829a24ceddf --- search.xml | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 55 insertions(+), 8 deletions(-) (limited to 'search.xml') diff --git a/search.xml b/search.xml index 83156457..22708457 100644 --- a/search.xml +++ b/search.xml @@ -3041,7 +3041,7 @@

体态

遇急重发热患者，应首先测呼吸、脉搏、血压等重要生命体征，并快速进行全面的体格检查，重点检查皮肤、黏膜有无皮疹、淤点以及肝、脾、淋巴结肿大等。发热伴有中毒性休克时，患者面色青灰，脉细速，血压下降或测不出，见于休克型肺炎、暴发性流行性脑脊髓膜炎、中毒性菌痢、脓毒症、流行性出血热等。

面容

一般急性感染多呈急热面容。伤寒、副伤寒者常表情淡漠，即所谓“伤寒面容”。斑疹伤寒、恙虫病、流行性出血热患者常呈醉酒样面容。猩红热患者见口周苍白。麻疹患者常见眼睑水肿、结膜充血、分泌物增多等。急性白血病、再生障碍性贫血和恶性组织细胞病常因贫血亦可呈面色苍白。发热伴面部蝶形红斑是播散性红斑狼疮的特殊病症。口唇疱疹可见于大叶性肺炎、间日疟、流行性脑脊髓膜炎、流行性感冒、大肠杆菌败血症等。

皮肤特征

注意有无皮疹及出血点。皮肤多汗可见于结核病、风湿热、败血症、恶性淋巴瘤。皮肤发疹可见于猩红热、麻疹、风疹、斑疹伤寒、伤寒、水痘、恙虫病、传染性单核细胞增多症、丹毒、红斑狼疮、急性皮肌炎等，根据其特征性皮疹及出疹日期可对急性发疹性传染病作出诊断:

-

根据特征性皮疹及出疹日期对急性发疹性传染病作出诊断.png

+

根据特征性皮疹及出疹日期对急性发疹性传染病作出诊断.png

注意有无皮疹及出血点。皮肤多汗可见于结核病、风湿热、败血症、恶性淋巴瘤。皮肤发疹可见于猩红热、麻疹、风疹、斑疹伤寒、伤寒、水痘、恙虫病、传染性单核细胞增多症、丹毒、红斑狼疮、急性皮肌炎等，根据其特征性皮疹及出疹日期可对急性发疹性传染病作出诊断。

淋巴结肿大

注意有无皮疹及出血点。皮肤多汗可见于结核病、风湿热、败血症、恶性淋巴瘤。皮肤发疹可见于猩红热、麻疹、风疹、斑疹伤寒、伤寒、水痘、恙虫病、传染性单核细胞增多症、丹毒、红斑狼疮、急性皮肌炎等，根据其特征性皮疹及出疹日期可对急性发疹性传染病作出诊断

脾大

注意有无皮疹及出血点。皮肤多汗可见于结核病、风湿热、败血症、恶性淋巴瘤。皮肤发疹可见于猩红热、麻疹、风疹、斑疹伤寒、伤寒、水痘、恙虫病、传染性单核细胞增多症、丹毒、红斑狼疮、急性皮肌炎等，根据其特征性皮疹及出疹日期可对急性发疹性传染病作出诊断。

@@ -3166,7 +3166,7 @@ 奥司他韦 /2023/03/05/%E5%A5%A5%E5%8F%B8%E4%BB%96%E9%9F%A6/ - 奥司他韦.jpg

+ 奥司他韦.jpg

目前市场上销售的达菲为罗氏制药独家生产的抗流感药物，其通用名称为磷酸奥司他韦（Oseltamivirphosphate）。奥司他韦（Oseltamivir）于1999年在瑞士上市，2001年10月在我国上市。达菲是一种非常有效的流感治疗用药，并且可以大大减少并发症（主要是气管与支气管炎、肺炎、咽炎等）的发生和抗生素的使用，因而是目前治疗流感的最常用药物之一，也是公认的抗禽流感、甲型H1N1病毒最有效的药物之一。

主要原理

奥司他韦口服后经肝脏和肠道酯酶迅速催化转化为其活性代谢物奥司他韦羧酸，奥司他韦羧酸的构型与神经氨酸的过渡态相似，能够竞争性地与流感病毒神经氨酸酶（NA，neu－raminidase，也有称作神经氨酸苷酶）的活动位点结合，因而是一种强效的高选择性的流感病毒NA抑制剂（NAIs），它主要通过干扰病毒从被感染的宿主细胞中释放，从而减少甲型或乙型流感病毒的传播。

特殊人群

    @@ -3530,7 +3530,7 @@ 气胸 /2023/03/01/%E6%B0%94%E8%83%B8/ - 气胸.jpg

    + 气胸.jpg

    这个病多见于瘦高的年轻男性，一般感觉起来就是：

    1. 胸腔有刺痛感，针刺的感觉，想想那种拿小针针撮你小胸胸的感觉。
      2. @@ -3538,7 +3538,7 @@
    2. 呼吸困难，就像有人捂住你的口鼻，有点窒息的感觉。

    通俗来讲造成这种感觉的原因是肺泡破裂，肺漏气了。然后气体在胸腔里聚集就压缩了肺。

    -

    气胸2.jpeg
    图中是一位右侧气胸患者（图中右面）的电脑断层扫描影像。在胸腔的边缘有着引流管，而图中黑色一片就是邻近于肺膜间(黑)和肋骨(白)的内腔。心脏则在图中央。医学专科胸腔医学、胸腔外科学症状胸痛、呼吸困难、疲劳常见始发于突发性肇因未知、创伤风险因子慢性阻塞性肺病（COPD）、结核病、抽烟诊断方法胸部X光、超声波、电脑断层扫描相似疾病或共病肺部大疱、血胸预防禁烟或戒烟治疗保守治疗、空针穿刺、胸管置放、肋膜黏连术盛行率约每10万人中20例外伤性气胸。

    +

    气胸2.jpeg
    图中是一位右侧气胸患者（图中右面）的电脑断层扫描影像。在胸腔的边缘有着引流管，而图中黑色一片就是邻近于肺膜间(黑)和肋骨(白)的内腔。心脏则在图中央。医学专科胸腔医学、胸腔外科学症状胸痛、呼吸困难、疲劳常见始发于突发性肇因未知、创伤风险因子慢性阻塞性肺病（COPD）、结核病、抽烟诊断方法胸部X光、超声波、电脑断层扫描相似疾病或共病肺部大疱、血胸预防禁烟或戒烟治疗保守治疗、空针穿刺、胸管置放、肋膜黏连术盛行率约每10万人中20例外伤性气胸。

    临床表现

    在医学上的临床表现中，气胸具有如下症状：
    患者常有持重物、屏气、剧烈运动等诱发因素，但也有在睡眠中发生气胸者，病人突感一侧胸痛、气急、憋气，可有咳嗽、但痰少，小量闭合性气胸先有气急，但数小时后逐渐平稳，X线也不一定能显示肺压缩。若积气量较大者或者原来已有广泛肺部疾患，病人常不能平卧。如果侧卧，则被迫使气胸患侧在上，以减轻气急。病人呼吸困难程度与积气量的多寡以及原来肺内病变范围有关。当有胸膜粘连和肺功能减损时，即使小量局限性气胸也可能明显胸痛和气急。

    初步诊断方式

    突发一侧胸痛，伴有呼吸困难并有气胸体征，即可作出初步诊断。X线显示气胸征是确诊依据。在无条件或病情危重不允许作X线检查时，可在患侧胸腔积气体征最明确处试穿，抽气测压，若为正压且抽出气体，说明有气胸存在，即应抽出气体以缓解症状，并观察抽气后胸腔内压力的变化以判断气胸类型。在原有严重哮喘或肺气肿基础上并发气胸时，气急、胸闷等症状有时不易觉察，要与原先症状仔细比较。

    类似病症需要区别开来

      @@ -3584,11 +3584,11 @@ 灯笼草 /2023/06/22/%E7%81%AF%E7%AC%BC%E8%8D%89/ 今天在菜园子里看到了野生的灯笼草，都结果了：

      -

      +

      灯笼果别名为小果酸浆、秘鲁苦蘵、打头泡、灯笼草等，茄科酸浆属多年生草本植物。
      灯笼果茎直立，叶较厚，阔卵形或心脏形，两面密生柔毛；花单独腋生，花萼阔钟状，花冠阔钟状，黄色而喉部有紫色斑纹，花丝及花药蓝紫色，花药长约3毫米。果萼薄纸质，淡绿色或淡黄色，浆果成熟时黄色，种子黄色，圆盘状，夏季开花结果。生于田间、路旁、村边。我国南北各地均有分市。

      不要与醋栗混淆

      醋栗长这样：

      -

      +

      性味

      • 《陆川本草》：”甘淡，微寒。”

        @@ -3869,7 +3869,7 @@ 肝功能检查化验单阅读指南 /2023/10/13/%E8%82%9D%E5%8A%9F%E8%83%BD%E6%A3%80%E6%9F%A5%E5%8C%96%E9%AA%8C%E5%8D%95/ -

        +

        • 谷丙转氨酶 （ALT）

            @@ -4132,7 +4132,7 @@ 血常规化验结果阅读指南 /2023/10/12/%E8%A1%80%E5%B8%B8%E8%A7%84%E5%8C%96%E9%AA%8C%E7%BB%93%E6%9E%9C%E9%98%85%E8%AF%BB%E6%8C%87%E5%8D%97/ 这里我给出一些常见的值，更详细的听医生说哦，我们以下图为例:

            -

            血常规化验单Demo

            +

            血常规化验单Demo

            • 红细胞 (RBC)
              • 正常情况： 男性 ， 女性
                • @@ -5547,6 +5547,53 @@ Software Engineering + + 领域驱动设计中聚合根持久化和事件发布可能导致数据不一致问题 + /2025/03/19/%E9%A2%86%E5%9F%9F%E9%A9%B1%E5%8A%A8%E8%AE%BE%E8%AE%A1%E4%B8%AD%E8%81%9A%E5%90%88%E6%A0%B9%E6%8C%81%E4%B9%85%E5%8C%96%E5%92%8C%E4%BA%8B%E4%BB%B6%E5%8F%91%E5%B8%83%E5%8F%AF%E8%83%BD%E5%AF%BC%E8%87%B4%E6%95%B0%E6%8D%AE%E4%B8%8D%E4%B8%80%E8%87%B4%E9%97%AE%E9%A2%98/ + 使用领域事件的一种直接做法是：在 应用服务 (Application Service) 中产生事件并发布出去。例如，对于“用户昵称更新”的场景来讲，对应的应用服务 UserCommandService 实现如下：

                +
                member public this.UpdateMyName (command: UpdateUsernameCommand) (user: User) =
                  let user = userRepository.GetById user.Id
                  let oldName = user.Username
                  let newName = command.Username

                  user.UpdateUsername newName
                  |> userRepository.Save
                  
                  UsernameChangeEvent (user.Id, newName, oldName) 
                  |> eventPublisher.Publish
                + +

                这里，在更新了用户姓名之后，即刻调用事件发布器 eventPublisher.Publish 将事件发送到消息队列中。虽然这种方式比较流行，但它至少存在两个问题：

                +
                  +
                1. 领域事件本应属于领域模型的一部分，也即应该从领域模型中产生，而这里却在应用服务中产生
                  2. +
                2. 对聚合根（本例中的 User ）的持久化和对事件的发布可能导致数据不一致问题。
                  3. +
                +

                对于第1个问题，可以采用“从领域模型中返回领域事件”的方式：

                +
                member public this.UpdateMyName (command: UpdateUsernameCommand) (user: User) =
                  let user = userRepository.GetById user.Id
                  let oldName = user.Username
                  let newName = command.Username

                  user.UpdateUsername newName // UpdateUsername 中构建 UsernameChangeEvent
                  |> fun user event -> 
                       userRepository.Save user
                       eventPublisher.Publish event
                + +

                这种方式保证了领域事件是从领域模型中产生，但仍然存在第二个问题。

                +

                第二个问题中所谓的“数据一致性”，表示的是将聚合根保存到数据库和将领域事件发布到消息队列之间的一致性。由于数据库和消息队列属于异构的数据源，要保证他们之间的数据一致性需要引入分布式事务。

                +

                但是分布式事务通常是比较重量级的，再加上当下的诸多常见消息队列均不支持分布式事务（比如Kafka），因此并不建议使用分布式事务来解决这个问题。

                +

                Transactional Outbox 便是一种方案，概括来说，这种方式将一个分布式事务的问题拆解为多个本地事务，并采用“至少一次投递（At Least Once Delivery）”原则保证消息的发布。具体来讲，发布方在与业务数据相同的数据库中为领域事件创建相应的事件发布表（Outbox table），然后在保存业务数据的同时将所产生的事件保存到事件发布表中，由于此时二者都属于同一个数据库的本地事务所管辖，因此保证了“业务操作”与“事件产生”之间的一致性。此时的代码变成了：

                +
                member public this.UpdateMyName (command: UpdateUsernameCommand) (user: User) =
                  let user = userRepository.GetById user.Id
                  let oldName = user.Username
                  let newName = command.Username

                  user.UpdateUsername newName // UpdateUsername 中构建 UsernameChangeEvent
                  |> fun user event -> 
                       userRepository.Save user
                       eventStore.Save event // 这儿用 eventStore 代替 eventPublisher 啦
                + +

                应用服务不再将事件直接发布出去，而是将事件保存到数据库中，之后，另一个模块将从数据库中读取事件并发布。

                +

                然而，这种方式依然有个缺点：每个需要产生领域事件的场景都需要应用服务先后调用repository.Save()和eventStore.Save()，导致了代码重复。解决方法也很简单——在聚合根中临时保存领域事件，然后在资源库中同时保存聚合根和领域事件到数据库。

                +

                在这种方式下，首先需要在聚合根的基类中完成与领域事件相关的各种设施，包括创建临时性的事件容器events以及通用的事件产生方法RaiseEvent()：

                +
                [<AbstractClass>]
                type IAggregateRoot = 
                  ...
                  let events = Collections.Generic.List<DomainEvent> ()

                  member private this.RaiseEvent (event: DomainEvent) =
                    events.Add event
                  
                  ...
                + +

                在聚合根基类AggregateRoot中，events字段用于临时保存聚合根中所产生的所有事件，各实际的聚合根类通过调用RaiseEvent()向events中添加事件。比如，对于“用户修改昵称”而言，User实现如下：

                +
                member public this.UpdateUsername (name: string, user: User) =
                  if this.Username = name then
                    ()
                  else
                    let oldName = this.Username
                    this.Username <- name
                    UsernameChangeEvent (user.Id, name, oldName) 
                    |> this.RaiseEvent
                + +

                这里，聚合根 User 不再返回领域事件，而是将领域事件通过AggregateRoot.RaiseEvent()暂时性地保存到自身的events中。之后在保存User时，资源库的公共基类BaseRepository的Save()方法同时完成对聚合根和领域事件的持久化：

                +
                member public this.Save<AR: when AR :> AggrateRoot> (it: AR) =
                  match it with
                  | null -> failwith "..."
                  | it when it.Events |> isEmpty |> not -> 
                    this.SaveEvents it.Events
                    this.CleanEvents ()
                  | _ -> ()

                  db.Save it
                + +

                在Save()方法中，首先获取到聚合根中的所有领域事件，然后通过SaveEvents()方法将它们保存到发布事件表中，最后通过db.Save it保存聚合根。需要注意的是，在这种方式下，AggregateRoot中的events字段是不能被持久化的，因为需要保证每次从数据库中加载出聚合根时events都是空的，为此在SaveEvents()保存了领域事件后，立即调用it.clearEvents()将所有的领域事件清空掉，以免领域事件随着聚合根一道被持久化到数据库中。

                +

                到目前为止，对领域事件的处理都还没有涉及到与任何消息中间件相关的内容，也即事件的产生是一个完全独立于消息队列的关注点，此时不用关心领域事件之后将以何种形式发布出去，Kafka 也好，RabbitMQ 也罢。除了关注点分离的好处外，这种解耦也使得系统在有可能切换消息中间件时更加的简单。

                +

                对于“在应用服务中通过eventPublisher.Publish()直接发布事件”而言，事件的产生和发布是同时完成的；但是对于“在聚合根中临时性保存领域事件”的方式来说，它只解决了事件的产生问题，并未解决事件的发布问题，事件的发布方应该采用“发射后不管(Fire And Forget)”的原则，即发布方无需了解消费方是如何处理领域事件的，甚至都不需要知道事件被哪些消费方所消费。

                +

                但是因为发送事件需要操作消息中间件，而更新事件状态需要操作数据库。在不使用分布式事务的情况下，此时的代码对于“事件发布成功 + 数据库落库成功”来讲是皆大欢喜的，但是依然无法排除有很小的概率导致事件发送成功了但是状态却为得到更新的情况。要解决这个问题，有一个选择是做妥协，即事件发布方无法保证事件的“精确一次性投递(Exactly Once)”，而是保证“至少一次投递（At Least Once）”。假设在事件发布成功之后，由于种种原因导致事件的状态未得到更新，即依然为CREATED状态，那么稍后，当事件兜底机制启动时，它将加载系统中尚未发布的事件进行发布，其中就包含状态为CREATED的事件，进而导致事件的重复投递。

                +

                “至少一次投递”将更多的负担转嫁给了事件的消费方，使得事件发送方得以全身而退。

                +

                事件消费的重点在于如何解决发布方的“至少一次投递”问题。举个例子，假设在电商系统中，订单子系统发布了“订单已成交”（OrderPlacedEvent）事件，积分子系统消费这个事件时会给用户新增与订单价格等额的积分，但是对事件的“至少一次投递”有可能导致该事件被重复投递进而导致重复给用户积分的情况产生。解决这个问题通常有2种方式：

                +
                  +
                1. 将消费方自身的处理逻辑设计为幂等的，即多次执行和一次执行的结果是相同的
                  2. +
                2. 消费方在数据库中建立一个事件消费表，用于跟踪已经被消费的事件
                  3. +
                +

                第一种方式是最理想的，消费方不用引入额外的支撑性机制，但是这种方式对消费方的要求太高，并不是所有场景都能将消费方本身的处理逻辑设计为幂等。因此，实践中主要采用第二种方式。

                +]]>                 + + Techinique + +                 关于 /about.html -- cgit v1.2.3