Algorithm

  1. 有效的字母异位词 （使用数组或者哈希表做计数器即可)
  1. class Solution:
  2.     def isAnagram(self, s: str, t: str) -> bool:
  3.         str_dict = {}
  4.         if len(s) != len(t):
  5.             return False
  7.         for c in s:
  8.             counter = str_dict.get(c, 0)
  9.             str_dict[c] = counter + 1
  11.         for c in t:
  12.             counter = str_dict.get(c, 0)
  13.             if counter == 0:
  14.                 return False
  15.             str_dict[c] = counter -1
  16.         return True

Review

一篇关于阿里seata 分布式框架的文章， 本质就是TCC + 二段提交， 需要一个全局的中央处理服务 (TC), 然后每个参与分布式事务的服务都要接入自身的RM, 这RM 的底层就是 Mysql 。 由TC 使用 TCC 协议控制全局的分布式事务，使得这部分控制代码集中起来，避免污染业务代码。
我觉得这种类型的服务/框架 更多的是适合金融行业的强一致性业务场景，底层是依赖DBMS 的 ACID 特性，与我之前理解的通用分布式事务还是有一段距离。 因为很多业务场景是不需要用DBMS, 但仍需要分布式业务，不过这个框架没有将这一层逻辑再进一步抽象。
image.png

Tips:

在我们日常中，常常需要为服务架构做决策，但做完决策后并不会刻意地将其保存起来，这其实是一种资源的浪费，因为在敏捷项目的开展过程中，架构决策是不断演进和变化的，如果我们将这些决策以时间的维度保存起来，那么每次做新决策的时候就会有一个依据。 Medium 里面有个架构师分享了一个不错的技巧, 就是LDAR, ADR 其实就是架构决策记录， 用于保存每一次架构决定的依据，目的和上下文。
image.png

ADR只要分为几个部分：

  1. Title — Title of the decision record.
  2. Decision — The decision that was made. For instance, use Elasticsearch for an enterprise-wide search API.
  3. Status — Status can be proposed, accepted _or _superseded. If you make any decisions and you need to change them later, you can simply add a new record with the changed status.
  4. Context — What is the context of this decision? It is important to capture the full context of the decision so that the reader knows the reasons behind it.
  5. Consequences — In this section, you can add what would happen if this decision is made. It is important to list all consequences, both positive and negative.

例子:
image.png

更多的例子

Share:

K8s 的核心概念， 最近一直在学习k8s 的相关资料，看到这篇文章总结得非常不错。K8s 由于理论体系比较庞大，涉及的组件和概念非常多，所以很容易让人迷惑。 这篇文章用很直白的类比方式来总结k8s的核心概念，很方便随时进行翻阅

K8s concepts we’ve seen. Here are the six levels of abstraction for a Deployment:

  • Deployment: manages ReplicaSets. Use for persistent, stateless apps (e.g. HTTP servers).
  • ReplicaSet: creates and manages Pods.
  • Pod_: _basic unit of K8s.
  • Node Cluster: Worker Nodes + Cluster Master.
    - Worker Nodes: machines for Pods.
    - Cluster Master_: _directs worker nodes.
  • Node Processes
    Master subcomponents:
    - API server: hub.
    - etcd: cluster info.
    - scheduler: matcher.
    - kube-controller-manager: cluster controller.
    - cloud-controller-manager: cloud interface.
    Worker Node subcomponents:
    - kubelet: Worker Node brain.
    - kube-proxy: traffic cop.
    - container-runtime: Docker.
  • Docker Container: where the app code lives.

image.png
image.png
image.png

image.png

image.png

image.png

Here are the 7 additional high-level K8s API objects to know:

  • StatefulSet: Like a ReplicaSet for stateful processes. Think state.
  • DaemonSet: One automatic Pod per Node. Think monitor.
  • Job: Run a container to completion. Think batch.
  • CronJob: Repeated Job. Think time.
  • Service: Access point for Pods. Think access point.
  • Volume: Holds data. Think disk.
  • PersistentVolume, PersistentVolumeClaim: System for allocating storage. Think storage claim.