当前位置:网站首页>Teach you to learn dapr - 5 Status management

Teach you to learn dapr - 5 Status management

2022-06-26 16:45:00 Masa technical team

Introduce

Use state management , Your application can treat data as key / It's worth it Stored in a supported state store .

Your application can use Dapr State management API Use the state storage component to save and read keys / It's worth it , As shown in the figure below . for example , By using HTTP POST, You can save the key / It's worth it , By using HTTP GET, You can read the key and return its value .

state-management-overview.png

characteristic

Pluggable state storage

Dapr The data store is modeled as a component , You can replace it without changing the code . for example :MySQL、Redis、Azure CosmosDB etc. .

Configurable state storage behavior

Dapr Allows developers to attach additional metadata to state operation requests , Used to describe how a request is processed . Such as :

  • Concurrent requirements
  • Consistency requirements

Default Under the circumstances , Your application should assume that data is stored Final agreement And use Last write wins The concurrency mode of

Concurrent

Dapr Support use ETags Of Optimistic concurrency control (OCC). When requesting status ,Dapr Always will be ETag Property to the returned state . When the user code attempts to update or delete the status , You should attach... Through the request body ETag To update or through If-Match Delete the header . Only if it's provided ETag And in the status store ETag When the match , Write operation can succeed . It is recommended that you use ETag When using Retrying strategy To compensate for such conflicts .

If your application omits... When writing requests ETag, be Dapr Skip... When processing requests ETag Check . And use ETag Compared to the write first win mode , This essentially enables Finally, win Pattern .

Automatic encryption

Dapr Support automatic client encryption of application state , And support key rotation . This is a preview function , all Dapr All state stores support .

Uniformity

Dapr Support strong consistency and final consistency , Final consistency As Default Behavior .

  • When using strong consistency ,Dapr Wait for all copies before confirming the write request ( Or appointed arbitration ) confirm .

  • When using final consistency , Once the underlying data store accepts the write request ,Dapr Will return immediately , Even if this is a single copy .

The batch operation

Dapr Two types of batch operations are supported - Batch (bulk) Or more (multi).

notes :bulk And multi The difference is that bulk Not transactional ,multi It's transaction processing .

Actor state

The transaction state store can be used to store Actor state . To specify for Actor State storage , In the metadata section of the state storage component, set the property actorStateStore The value of is specified as true.

notes :Actors The state is stored in the transaction state store in a specific scheme, allowing consistent queries . So only one state storage component can be used for all Actor.

Directly query the status store

Dapr Save and retrieve status values without any transformation . You can query and aggregate state directly from the underlying state store .

for example , To be in Redis Get the information related to the application ID “myApp” All associated status keys , Please use :

KEYS "myApp*"

Inquire about Actor state

If the data store supports SQL Inquire about , You can use SQL Query the status of participants . For example, using :

SELECT * FROM StateTable WHERE Id='<app-id>||<actor-type>||<actor-id>||<key>'

You can also cross Actor The instance executes an aggregate query , avoid Actor The common round based concurrency limitation of the framework . for example , To calculate all thermometers Actor And the average temperature of , Please use :

SELECT AVG(value) FROM StateTable WHERE Id LIKE '<app-id>||<thermometer>||*||temperature'

Save and get status

State management is one of the most common requirements of any application : New or legacy 、 Monomer or microservice . Dealing with different databases 、 test 、 Handling retries and failures can be time-consuming and laborious .

precondition

Get ready Dapr The running environment can be seen in the previous article

Hands teach you how to Dapr - 3. Use Dapr Run the first .Net Program

Set the status store

Windows Open Directory %USERPROFILE%\.dapr\components

  1. create a file statestore.yaml

  2. Use redis A database stored as a state

    apiVersion: dapr.io/v1alpha1kind: Componentmetadata:  name: statestorespec:  type: state.redis  version: v1  metadata:  - name: redisHost    value: localhost:6379  - name: redisPassword    value: ""  - name: actorStateStore    value: "true"

    notes : This yaml Have gone through actorStateStore Open the Actor state

Save and retrieve individual states

notes : Set up app-id Very important , Because the status key prefixes this value . If you don't set it , Then a... Is generated for you at run time , The next time you run this command, a new , You will no longer be able to access previously saved States . let me put it another way , If you want to share status, you can customize a reservation app-id As a shared state instead of leaving blank .

function Dapr Sidecar

Run an empty Sidecar, Because we only use it to help access the state store , So different from before ,dapr run There's no answer in the back dotnet run To be the of a program Sidecar

dapr run --app-id myapp --dapr-http-port 3500 --dapr-grpc-port 50001

Create client

Create a console program , add to Dapr.Client NuGet Package reference .

modify Program.cs

using Dapr.Client;var storeName = "statestore";var key = "myFirstKey";var value = "myFirstValue";var client = new DaprClientBuilder().Build();await client.SaveStateAsync(storeName, key, value);Console.WriteLine("State has been stored");var data = await client.GetStateAsync<string>(storeName, key);Console.WriteLine($"Got value: {data}");Console.ReadKey();

Delete a single status

await client.DeleteStateAsync(storeName, key);

Save and retrieve multiple states through transactions

Dapr It also allows you to save and retrieve multiple states in the same call .

var lst = new List<StateTransactionRequest>(){    new StateTransactionRequest("test1", System.Text.Encoding.UTF8.GetBytes("value1"), StateOperationType.Upsert),    new StateTransactionRequest("test2", System.Text.Encoding.UTF8.GetBytes("value2"), StateOperationType.Upsert),};await client.ExecuteStateTransactionAsync(storeName, lst);var datas = await client.GetBulkStateAsync(storeName, lst.Select(r => r.Key).ToList(), 0);Console.WriteLine($"Got items: {string.Join(",", datas.Select(d => $"{d.Key}={d.Value}"))}");

Strong consistency

When using strong consistency ,Dapr Will ensure that the underlying state is stored before writing or deleting the state , Once the data is written to all copies or received from quorum Of ack, It will return a response .

about GET request ,Dapr Will ensure that the latest data stored between replicas is consistently returned . The default is final consistency , Unless in the right state API Otherwise stated in your request .

await client.SaveStateAsync(storeName, key, value, new StateOptions() { Consistency = ConsistencyMode.Strong });var etagData = await client.GetStateAndETagAsync<string>(storeName, key, ConsistencyMode.Strong);Console.WriteLine($"ETag:{etagData.etag}");await client.DeleteStateAsync(storeName, key, new StateOptions() { Consistency = ConsistencyMode.Strong });

Write win first and win last

Dapr Allows developers to choose two common concurrency modes when using data stores : First write win and `` Last write wins `. First-Write-Wins Useful when you have multiple application instances , All instances write the same key at the same time .

Dapr Of Default The pattern is Last write wins .

The following example shows how to get a ETag, Then use it to save the State , Then delete the status :

await client.SaveStateAsync(storeName, key, value, new StateOptions() { Concurrency = ConcurrencyMode.FirstWrite });var firstWriteWinData = await client.GetStateAndETagAsync<string>(storeName, key);var etag = firstWriteWinData.etag;await client.TrySaveStateAsync(storeName, key, DateTime.Now.Ticks.ToString(), etag, new StateOptions() { Concurrency = ConcurrencyMode.FirstWrite });var firstWriteWinDeleteSucceeded = await client.TryDeleteStateAsync(storeName, key, etag);Console.WriteLine($"First write wins delete:{firstWriteWinDeleteSucceeded}");firstWriteWinData = await client.GetStateAndETagAsync<string>(storeName, key);firstWriteWinDeleteSucceeded = await client.TryDeleteStateAsync(storeName, key, firstWriteWinData.etag);Console.WriteLine($"First write wins delete:{firstWriteWinDeleteSucceeded}");

notes : Here's a demonstration of ETag Try to delete the failed example after the update , Finally, get a new state again to correct ETag And then delete

Share state between different applications

In order to achieve state sharing ,Dapr The following key prefix policies are supported

  • appid - This is the default strategy . appid Prefix allowed status can only be specified by with appid Application management . All status keys will start with appid The prefix , And take the application as the scope .
  • name - This setting prefixes the name of the state storage component . For a given state store , Multiple applications can share the same state .
  • none - This setting does not use the prefix . Multiple applications share state between different state stores

for instance : To specify a prefix policy , Please add a component named... On the status component keyPrefix Metadata key for

apiVersion: dapr.io/v1alpha1kind: Componentmetadata:  name: statestore  namespace: productionspec:  type: state.redis  version: v1  metadata:  - name: keyPrefix    value: <key-prefix-strategy>

notes : This example demonstrates a relatively complex , The idea is probably to use multiple statestore.yaml, Then according to different storename Switch between different strategies . Interested partners can try it on their own .

Automatically encrypt state and manage key rotation

notes : So far , This feature is a preview , Interested partners can try it on their own

Application state usually requires static encryption , To provide greater security in enterprise workloads or regulated environments . Dapr Offer based on AES256 Automatic client encryption .

The lifetime of the State (TTL)

Dapr Set the lifetime on request for each state (TTL). This means that the application can set the lifetime for each stored state , And these states cannot be retrieved after expiration .

notes : There's only a part of it Dapr State storage components and states TTL compatible . For supported state storage , Just set... When publishing a message ttlInSeconds Metadata . Other status stores will ignore this value .

await client.SaveStateAsync(storeName, key, value, metadata: new Dictionary<string, string>() { { "ttlInSeconds", "3" } });var ttlData = await client.GetStateAsync<string>(storeName, key);Console.WriteLine($"TTL Data:{ttlData}");Thread.Sleep(5000);ttlData = await client.GetStateAsync<string>(storeName, key);Console.WriteLine($"TTL Data:{ttlData}");

Persistent state

To explicitly set the persistence state ( Ignore any... Set for the key TTL), Please put ttlInSeconds Value specified as -1.

Source code of this chapter

Assignment05

https://github.com/doddgu/dapr-study-room

We are acting , New framework 、 New ecology

Our goal is The freedom of the Easy-to-use Highly malleable functional Robust .

So we learn from Building blocks Design concept of , Working on a new framework MASA Framework, What are its characteristics ?

  • Native support Dapr, And allow Dapr Replace with traditional means of communication
  • Unlimited architecture , Single application 、SOA、 Micro services support
  • Support .Net Native framework , Reduce the burden of learning , In addition to the concepts that must be introduced in a specific field , Insist on not making new wheels
  • Rich ecological support , In addition to the framework, there are component libraries 、 Authority Center 、 Configuration center 、 Troubleshooting center 、 A series of products such as Alarm Center
  • Unit test coverage of the core code base 90%+
  • Open source 、 free 、 Community driven
  • What is the ? We are waiting for you , Come together and discuss

After several months of production project practice , Completed POC, At present, the previous accumulation is being refactored into new open source projects

At present, the source code has been synchronized to Github( The document site is under planning , Will gradually improve ):

MASA.BuildingBlocks

MASA.Contrib

MASA.Utils

MASA.EShop

BlazorComponent

MASA.Blazor

QQ Group :7424099

Wechat group : Plus technology operation wechat (MasaStackTechOps), Remarks , Invite in

masa_stack_tech_ops.png

原网站

版权声明
本文为[Masa technical team]所创,转载请带上原文链接,感谢
https://yzsam.com/2022/02/202202170506437956.html